{ Part One of this blog discussed 3 factors to consider when planning a true Design Sprint. Be sure to read both blogs in order to get the most accurate depiction & implementation of this important business process, as laid out by our User Experience Designer, Kevin Guenther. }
Choose the right problem! The next biggest challenge to running a successful Design Sprint is ensuring you’re working on a clear problem. One that everyone agrees is in fact a problem, and one that can be tested and validated clearly by having your target users interact with a prototype.
This is equally challenging and even more important when you’re spreading the Design Thinking processes over a longer period of time. It’s hard enough to keep your goals and guiding questions in mind as you work through the process — but if you haven’t clearly defined the narrative you will be focusing on for your prototype, you’re bound to fail.
If you’re concerned that the problem isn’t a clearly defined one, as in;
- Everyone agrees on the same problem as the priority,
- The goal of your problem and the key questions address it directly, and
- Your prototype can be designed using a narrative that can answer your key questions…
You should stop the process as early as possible and dig into more user research before you proceed.
Diverge and converge
The concept of diverging and converging or working alone-together in a Design Sprint is a powerfully effective concept originally conceived of at IDEO as a part of their Design Thinking philosophy. This principle is based on research that showed traditional group think (often referred to as brainstorming sessions) are ineffective at best.
Too often, ideas that are brought out by the most vocal, extroverted folks in the group are the ones that get developed. Which means that sometimes the best ideas don’t get the attention they deserve because they’re trapped in the minds of the shyer more introverted individuals. However, in most of the cases I’ve seen, it’s the ideas from the senior executive or department manager in the room that get pushed through (even if they’re bad), because the rest of the team is less inclined to challenge them.
Using the diverge/converge philosophy, the team toils on a task on their own, then presents it to the rest of the group. In a Design Sprint, this is taken a step further where everyone works on a task, like the storyboard task for example, then hand it back to the facilitator, who tapes them up on the wall for everyone to vote on with dot stickers. This further anonymizes the process, so nobody knows who anyone else’s ideas are except their own. In this way, everyone’s idea gets an equal amount of attention and usually the results are a hybrid of all the best components.
In cases where your process will span several weeks, this concept can also work extremely well. However, it requires your team members to do a little work during their day that isn’t necessarily a part of their everyday role. But as long as your team members are engaged in the process, that shouldn’t be a problem and it really helps to bring down the average meeting time. Of course, this only works with some of the exercises traditionally performed in a Design Sprint. You can reference the recommended schedule below to see which exercises I recommend having your team do on their own time.
To Sprint, or not to Sprint
Given the nature of the tasks that make up a Design Sprint, and using the concept of diverge/converge effectively, it is certainly possible to produce similar beneficial results form a Design Sprint process spread out over a few weeks rather than committing to the one-week sprint. But in my opinion, while an entire week of committing to a Design Sprint may initially seem like you’re losing precious time from your everyday job, the reality is that it requires far more effort to maintain a task-force that performs these exercises over a longer period of time.
The momentum and enthusiasm you lose as the process gets longer, can wear the team down and create situations where participants end up missing meetings and ultimately affect the quality of the prototype and the user-test results.
Another client, enthusiastic about running a Design Sprint in her organization put it really well to me. She said, “none of the people I’m going to ask to participate would complain about losing a week of work to a Professional Development workshop, or conference. I don’t see why they should see this as any different.”
I couldn’t agree more.
In the previous team example I gave, a concern over the same complaint of, “losing a week”
is what prevented the product owner from even attempting to ask the group to do a Design Sprint with us. But in hindsight, had they decided instead to give the team two weeks’ notice before we started a Design Sprint for adequate scheduling time—we would have been done our testing two weeks earlier.
In the end, the group produced some great learnings, and the project did begin development on time (just under the wire) … but the effort to get there now serves as an excellent example of why the team at Google Ventures found the format they finally ended up publishing in Sprint, so effective.
Recommended DTP Schedule
If you find yourself in a situation where you’re unable to get your team to commit to a Design Sprint, I’ve put together a diagram that breaks down the traditional 5-day schedule of a Design Sprint into a recommended meeting schedule that we think works best.
Submit a Comment