Testing a new feature idea by using the Design Sprint methodology.
I planned and co-ran a Design Sprint for McKinsey & Company. The aim of this Design Sprint was to design, prototype and test a new feature idea for the internal McKinsey & Company application. The nature of the resulting work is confidential, but I would like to talk about how we approached the process and what I’ve learnt.
Brand
McKinsey & Company
Agency
Edenspiekermann
My role
Sprint Facilitator and Designer
Sprint agenda
Client wanted to run through the five phases of the sprint in three days so we planned for the following agenda:
- Day one - understand and define
- Day two - ideate and decide
- Day three - prototype and learn
Understand and define
Day one of the sprint was all about trying to understand what we were trying to solve. In this phase, I moderated a bunch of exercises, such as, lightning talks, which helped to unlock each participant’s knowledge; “How Might We” session and affinity mapping that helped to reframe problems as opportunities; and user journey mapping that helped to dive deep into user experience. As an external facilitator, my task was to ask the right questions to help the participants focus and ensure that understanding and definition of the problem is complete.
As a result of day one, team agreed upon the goal and business opportunity for the sprint, defined the problem of the new feature and aligned on priority audience.
Ideate and decide
In day two, we gave sprint participants time and space to brainstorm on their own and generate a broad range of ideas. Although the participants seemed intimidated by the task at first, they ended up doing great in coming up with detailed sketch solutions on paper.
After individual presentations, we voted for the best solutions and decided as a team what to prototype in order to best answer our sprint questions. We ended the day with creating a storyboard that defined each interaction with a user in a step-by-step process. This became the specification for our prototype.
Prototype and learn
In day three, my colleague and I had to create and present a finished prototype to the client.
This is where we diverged from a regular design sprint process a bit because although we built the prototype, its validation sessions were up to the client to conduct in a few days following the sprint. We used Keynote to built this interactive prototype which client successfully used across the organization to test their hypothesis.
Conclusion
Not every problem needs a design sprint, but it worked really well for the team at McKinsey & Company. In only three days we succeeded in answering a few important business questions and produced something tangible. Personally, I was glad to learn a bunch of Design Sprint techniques that I now enjoy using as a part of my team's design process whenever we need to increase creativity and quickly generate new ideas.