What we learned from doing design sprints
A few months ago we conducted our first design sprint, a process for exploring and creating new ideas in the span of 5 days, as outlined by Google Ventures. Over the course of that week, we spent a lot of time understanding the landscape, brainstorming ideas, deciding on a direction, prototyping, and testing with users. All in all, it was a great way to learn about your product without actually building and launching it.
I won’t be going too in-depth about what sprints entail, but if you want to read more about the process, I highly recommend reading the book Sprint by Jake Knapp. It will tell you everything you need to know about doing one of your own.
What I will be going over are some of the things the team learned after sprinting three times over six weeks (if that sounds like a lot, you’re right — stay tuned). So if you’re someone who knows what these sprints are about but want to hear a little bit more from the front lines, this is for you.
1. Know why you’re doing the sprint.
Yes, we get it, “design sprints” are the innovation flavor of the day, but seriously, don’t do it just because you’ve heard about it and it sounds like it will solve all of your problems. It’s not a panacea. Make sure the team is aligned on what has necessitated this sprint. The reason can’t be: let’s just see what happens.
2. Tackle a big problem.
While it won’t solve all your problems, it can help you chip away at a big problem. The bigger the challenge, the better. How else are you going to justify pulling 4–7 important people out of their day-to-day for a whole freaking week to focus on this? Don’t focus on quick wins or nice-to-haves. This is the time to dig deep. Design sprints sort of happen in the Mirror Dimension where you can take big risks and stand to “fail”. After it’s done, you haven’t really lost anything — maybe a week of time — and you’ve probably gained some very valuable insight, even if it’s just what not to do.
3. Make it fast.
One of the best things about design sprints are their condensed nature. In just one week, you can interview stakeholders, brainstorm ideas, outline a hypothesis, create a prototype, and test it with real users. And you get to take people from multiple corners of the organization along for the ride. It’s a nice little microcosm for a design process based in design thinking principles. It’s great when maybe you’ve been waffling for quite some time over an issue and need to just do it. However, it can’t replace a robust design process. So use this when you need a good jumpstart as you’re barreling towards some sort of deadline or decision point, not as a recipe for long-term decision-making. There’s a reason why they call it a sprint and not a leisurely jog.
The crunched nature of the sprint is also partially by design. The timeline forces everyone to drive towards actually making and testing something instead of talking in circles, going back and forth on direction. It ensures a focused, intense week, getting everyone working on the same thing together. It would be an emotional, not to mention logistical, nightmare to apply that kind of singular focus over an extended period of time.
4. Keep the team small.
The Sprint book recommends 4–7 people per sprint, and I completely agree with this. When you have too many people, accountability goes down. People aren’t as engaged, knowing that others in the room can pick up the slack. With a small lean team, everyone has a big share of the work to do, and are bound to take it seriously. Conversation flows freely, and it’s easier to collaborate. If there are other stakeholders you’d like to include but they just can’t dedicate the time, or are ancillary to the core team, have them come in on day one to drop some knowledge or on day three, to review concepts and be part of the voting process.
5. Pick the right people.
With such a small team, the right balance of roles in the group is extremely important. Before going into the sprint, think about your goals and what the prototype might look like. Choose experts based on the goal of the sprint. The team should represent the organization, representing business, marketing, design, technology, or other relevant functions, mixing people with domain expertise with people who will work on the day-to-day team. If you have a team of mostly designers working on the sprint, for example, you’re missing valuable, real-time insight from other sides of the organization, and issues will certainly crop up after the sprint is finished.
Most important of all is making sure the team has an established decision maker. Completing a sprint only to get the idea stopped by someone with decision-making power who wasn’t involved is extremely counterproductive. When the decision maker is a part of the sprint, they see how the ideas are formed, hear where people are coming from, and can also make the tough calls that arise in the sprint. The entire team is empowered, knowing that they have buy-in to move forward with their ideas.
6. Don’t do sprints back-to-back.
Design sprints should be few and far between. They are time-consuming and require a lot of energy. As much as we would all like to be hyper-focused on one thing for a week at a time, it’s not usually feasible in the typical work setting. We learned this the hard way. We decided to do three sprints, with about a week or less in between each. The first sprint, we were excited and raring to go. The second sprint ended up being an extension of the first, and we didn’t necessarily cover a lot of new ground. The third sprint, we decided to work on a different problem, but it was clear that it was hard to keep the level of enthusiasm and focus that we had in the first sprint.
Going back to #1, sprints need to tackle a big problem. If you really have three big subsequent problems to solve, think about whether they are truly big enough, or if one overshadows the others. Schedule a healthy amount of time after the sprint to debrief, tweak the prototype or change direction based on what you learned, do some additional user interviews, stakeholder interviews, usability testing, whatever action items come out of the sprint. Keep in mind, these activities don’t have to happen in the format of a sprint. However, you can certainly adopt sections of the sprint as you see fit.
There are a lot of benefits to the rigid structure of a sprint. But once the sprint has been completed, the structure of what happens next should be widely dictated by your learnings. And usually, that doesn’t mean running a whole other sprint. If you must, try to have at least one month between sprints, but I recommend even more time than that.
7. Don’t get hung up on the prototype.
You don’t necessarily need a prototyping expert or design whiz on the team to create a prototype. The sprint is an opportunity to learn, so think about the minimum viable prototype you need to make that happen. Don’t underestimate the power of wizard of oz prototyping. Get creative, and don’t let technology limitations get in the way.
8. Follow the book, but find your own way.
My last point is fairly simple. If it’s your first time running a sprint, try to follow the structure that’s been outlined in the Sprint book. The authors have so much trial-and-error experience under their belts, it makes sense to believe there’s a reasoning behind every step. However, it’d be naive not to acknowledge that every situation is different. Once you’ve run through the sprint, by the book, assess how it went. Which parts worked really well, and which parts could be changed to better fit what you need? Like the prototype in the sprint, the sprint itself is also an experiment and work-in-progress. Run the sprint, then modify it and make it better for you and your organization. Good luck!
I’ve just included eight major learnings here, but we learned countless things from this process. If you have any questions or your own sprint stories, we’d love to hear from you. Tweet us @weareprolific or respond directly here!
Special thanks to Cassie Wallace for her insights and being my partner-in-crime in this process.
