That’s why we work in design sprints — it forces accountability and keeps projects focused and on track. Planning and executing these, however, can be a daunting task.
Here’s how you do it.
What is a design sprint?
A design sprint is an approach where you define a very discrete design problem and develop the solution over a short “sprint” (usually 5 days). A design sprint is generally comprised of 5 steps:
- Understand
- Ideate
- Decide
- Prototype
- Test
The idea is that you run through this process, take your learnings, and repeat the process to rapidly come to a functional design to scale to a larger project.
Before you start: planning your sprint
Because a design sprint needs to happen very quickly, you need to have a good plan of attack for when you engage the entire sprinting team. In this stage, you need to have a few key pieces.
- The problem you’re solving. Have you defined the problem clearly? Is it well understood, solvable within 1 sprint, and worth the significant effort you’re about to put in, both from a customer and organizational perspective?
- Access to customers. You’re going to be talking to and testing in front of actual customers. Do you have these lined up?
- Assemble your team. Are the right people in the room who need to be there to make sure your design sprint is successful? Do they know what they’re there to do? Are they committed? The usual suspects are design, marketing, product, and senior leadership to represent business interests.
- Write your design brief. A design brief is: “a short document (one-pager) that defines the design challenger, explains the constraints, and sets a timeline for the launch of the product or deliverable.” This needs to be written, circulated, and confirmed by all participants before you start.
Once all this is in place (and this step can take several weeks) you’re ready to embark on your design sprint. It can be tempting to rush this stage but resist! More time spent here will make the rest of the spring go a whole lot smoother.
1. Understand
The objective here is to deeply understand the problem you’re solving. You likely started this sprint with an organizational problem, but the key here is to understand the customer pain points, and outline where you want to be in 6/12/24 months.
At this stage, the focus is to bring together lots of different perspectives from your sprint participants and aggregate them to better understand the problem you’re solving, and why. There are literally dozens of ways to tackle this, but a few common techniques include:
- User journey mapping
- How We Might (HWM), where the team reframes problems as opportunities
- User Interviews
- Empathy mapping
2. Ideate
Now that you have a good team understanding of the problem, you need to work on the solution.
The point of this step is to map out every possible solution to the problem you’ve identified. Deciding on the best solution comes next, so at this point it’s about getting as many viable options on the table.
Common tactics include:
- Lightning demos, when you look for how other people are already solving your problem
- The four-step sketch method
- Crazy 8s, when you take one solutions and brainstorm 8 variations in 8 minutes
3. Decide
Decision time. You have the problem, you have dozens of solutions - now you need to decide as a team what one you’re going to pursue.
This stage can be as simple or as complex as you like. One option is a simple voting system, where everyone gets 3 minutes to present their idea, then everyone gets 3 votes to cast. The idea with the most votes is the winner.
An alternative is the silent vote method, where the sketches are presented silently and evaluated essentially in private, to avoid the best pitch person winning out rather than the best design.
At the end of this stage, the team should have a single idea to pursue.
4. Prototype
Time to put your idea into action. You need to actually build a prototype that’s going to be good enough to give users the concept, but quick enough that if it fails dismally you’re not completely sunk. Remember, this also has to be done within 1 day.
The key is to make it believable, but no more. This means making the story, stitching it together in a comprehensible way, and dropping in any assets or copy that you need so users believe what they see. This is also the stage when you need to write your user interview script, so you can guide the users on the prototype. A good script means you can build a more limited prototype, so it’s well worth putting in the work there.
5. Test
Finally, you need to test it out.
This when you put your idea in front of users and see if it actually works and solves their problem, as well as an opportunity for you to get some feedback.
Remember: this is a small test. You don’t need to test hundreds of people to learn. You need to test 5-8 people to pull out the themes of what’s working and what isn’t.
What Happens Next?
A design sprint should kick off a larger conversation or project. You’ve hopefully validated a functional solution — now it’s time to turn it into reality.
A (less successful) alternative is that the design sprint failed. Maybe the selected solution didn’t solve your user problem, in which case you can go back and repeat your decide / prototype / test sprint. Alternatively, you can revisit your sprint from the beginning.
One important piece to remember is that no sprint is perfect. It’s worth taking time to post mortem the sprint itself:
- Were the right people involved?
- Did your conversation get dominated by a few noisy people?
- Was the problem well scoped and well understood? Was the problem worth solving?
- Did you get full commitment from the people involved?
A design sprint is hard work. But it’s one of the best ways to quickly identify and solve key problems. Give it a try, and you’ll be surprised at how quickly design can make a huge impact on the business.
