Case Study: The Signal Noise Playbook
A new production standard for a data design studio
Overview
Signal Noise is known for making data experiences that delight users. We blend information design with user experience and creative technology to surface insights and change behaviour.
When I started at the company, Signal Noise had no production unit or team to speak of. Over the last 18 months, we have taken on the challenge of redefining how we execute projects for clients, users, teams, and the business.
We designed and developed the very first Production System called The Signal Noise Playbook. We took inspiration from design systems like IBM’s Carbon because we believe that the world needs production systems for the same reason we need design systems.
To do this we used the same techniques we often use with our clients on ourselves, if we were users of a new product or service, what are our pain points? What can we leverage and improve?
Out of these insights we created principles & reusable components that solved those pain points. Then we turned those components into ‘plays’ and taught teams how to execute them.
Within weeks of launching, we could see the effects; profit margins started going up, teams began saying they were collaborating more, and there was less time spent in meetings. Hoorah!
What We Did
- User Research
- Production Strategy
- Workshops
- Process Design
- Coaching
Qualitative Outcomes
“As we create bigger more ambitious solutions at the intersection of insight and action, we needed to codify how we work internally and with clients in a way that could continually evolve — the playbook is about working with intention, and continual self-reflection. How are we doing today? What can we as a team do better tomorrow?” — Victor Szilagyi, Global Practice Lead
“Having a clear production methodology, and one which is responsive to the needs and learnings of the team is a source of pride as well as being a big help in managing our work with a very variable roster of talent. It gives everyone a sense of security that there’s a way to do a given thing, that it’s been thought about, and that things won’t be left to chance — everything you could want from a production team!” — Marcel Kornblum, Technical Director
3 Big Takeaways
01.
Reducing business risk
02.
Aligning production with business objectives
03.
A scalable system that can build
Reducing Business Risk
Redefining phases to reduce risk
By redefining the project phases we were able to introduce techniques that reduce the risk of over-promising solutions that are too expensive right at the beginning. Additionally, we allowed our teams time to discover the real needs of the business and its users, before prescribing a solution. We separated the statement of work and the scope of work. The scope of the work became defined at the end of a Discovery phase. This was done as a Method Statement.
Controlling The Solution
To enable that the solution we were presenting in our Method Statements would fit inside the budget we had, we determined a way of measuring the effort. Estimations are never an exact science, but with the right team and enough time we found that we could make decisions that protected our profits significantly. This was done using a scoping tool that allowed us to:
- Define the skills needed
- Estimate the efforts
- Prioritise features
- Define which features might be deprioritised to ensure profits were protected
Introducing Impact Early
We used a cause-effect framework to communicate the impact of different types of delay. We had to be able to explain the impacts on production, and therefore create a justification for why we would need more time and budget if they occur. We chose the 3 most common, and most costly issues; new stakeholders missed reviews and missed milestones. This made our clients clearer on their responsibilities, improved production, and made conversations easier when things didn’t go to plan.
Align production with business objectives
Ensure business objectives set direction
We designed a single focused session to enable senior management to feed the team leads with the business priorities for the next 30 days. From these priorities, we used a Kanban board to visualise the state-of-play. Cards for each new play defined how each play would achieve the business objective.
Ensuring teams were trained and coached
A big part of that is taking the Plays out of a project context, and understanding them as a separate entity that can be taught and improved. So, Plays are designed to be taught outside of a project context, and individuals are coached on their performance by a pier in their execution of it.
Embracing failure
We borrowed from Agile and added retrospectives to our sprints and closing of projects. But we enhanced the value of the learnings: we built a database of the knowledge gained. When project teams experienced issues or blockers to business objectives, we documented the data and created a spreadsheet that could be filtered. When starting new projects of similar types we could revert back to the database and remind ourselves of the knowledge gained. A mind palace for production.
A scalable system that can build
Bigger than the sum of its parts
Critical knowledge was being lost every time someone moved on, setting the whole business back. We knew we need to build a system that could outlive any single person who uses it. It also needed to be easily accessible, digestible and have good user interface design. We decided to use a wiki software tool called Notion for all those reasons.
Used for onboarding into the culture
Once the playbook was launched it became the de-facto tool for onboarding new joiners into how we work. Using the Plays and Loom videos we were able to reduce the effort required and increase the quality of onboarding. New joiners could also onboard at the pace that they preferred, or as projects dictated it.
Developed from teams up
Each play is designed to be developed by the teams that use it. In the creation of the Playbook, we wanted to empower teams to improve the plays by editing the pages and capturing improvements in a changelog.
We created a framework for change because we know that a production system is only as good as the belief that each team has in it.
