An evil, hipster voice inside me says: I did design sprints before it was cool. But it is true, years ago when there were no books about it, and far fewer blog posts, we were doing design sprints at UX studio. It started as a natural step to sync our work to developers’ sprints and to make sure we designers were consistently iterating. Now, we use weekly design sprints as part of our ongoing design process.
In this article I will share what we’ve learned so far, how we’ve adapted the original idea of design sprints to our team, and some ideas about adopting design sprints to continuous development.
What is a design sprint?
Since the agile revolution in the IT industry, many development and design teams organize their work into sprints. As Monika Adarsh explained in her team’s experience with Google Venture’s design sprints, a sprint is a fixed timeframe, usually between 1 and 4 weeks, during which a finite amount of work can be accomplished. Each sprint starts with planning, where the team agrees upon what they will accomplish during the sprint. At the end of the sprint, the team gathers to review what was completed and discuss what could be improved upon.
Design sprints are a part of the agile landscape. The idea is that by time-boxing the design process and adhering to a set of goals (Understand, Diverge, Converge, Prototype, and Test), the team has a chance to consider a problem, try it out, make mistakes, and try again – all in a very short period of time. Developed at GV (Google Ventures), design sprints last a week. In their own words, this is what GV’s schedule is like:
On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.
—The Design Sprint
People wonder if it is sustainable to complete a sprint every single week. It’s a lot to accomplish: choose a serious challenge, do prototyping and research, involve stakeholders, etc. But believe me, working in design sprints is still better than waterfall. That said,our team has modified GV’s original recipe to fit our needs, with a focus on these four areas:
- the participants
- the structure and timing
- the planning
- the goals
Getting Everyone on Board
The hidden magic of the design sprints is participation. When teams schedule a single week for collaboration, everyone gets invited: business leaders, developers, designers, sometimes even the whole product team. This creates team alignment: everyone is aware of the important findings, so that the implementation will go smoothly afterwards. However, when every week is a design sprint, it’s unsustainable to ask everyone to participate. They have their own jobs to do!
When your team decides to implement design sprints, the first step is to get buy-in from the whole product org. This shouldn’t be too hard—they won’t have to do much, after all most of the work (prototyping, design and research) will be done by the designers and UX researchers. The only ask is that some members join the weekly brainstorming sessions (more on that later).
We believe it is vital to include all departments in the design process. When teams are left out, it can end in disaster. When those left-out departments finally see the results of the design process, they may raise an unknown issue—leading to tense discussions and last minute changes. It’s better to involve everyone, and show them how the design is born step-by-step. This gives all teams the chance to put in their ideas and raise any concerns.
Our Weekly Sprint
After your product team has agreed to the design sprint, it’s time to figure out your cadence. Our design sprint lasts one week. While we do have an expected pace, we do not establish rigid goals for each day. After all, my designers are the pros. I trust them to do the ideation and elaboration part in their own pace.
As you get started, it can be hard to maintain a rigid structure. When that happens, remember the core goal of design sprints: choose the problems, design the solutions, and test them in the same sprint.
The cadence that works well for our team is to spend 1 day meeting, 2 days designing, and 2 days testing.
Monday: Weekly Design Meeting
A sprint starts with the weekly design meeting. This meeting is our main forum for collaboration, and while everyone from the product team is invited, it is mandatory that a teammate from business and development attends. Why those two departments? Business people help designers to focus on the main business objectives and give the authority and the resources the design team needs. Devs help designers stay on the ground, and design something that is feasible to build.
We also use these meetings to share research results from the previous sprint. This way, design, development, and business agree upon the direction of the sprint and are up to speed on why designers are making certain choices.
Tuesday—Wednesday: Designers are head down
After the design meeting, the team gets to work. Figuring out many issues to tackle in a sprint is more of an art than a science. In general, we’ve found that 2, or a maximum of 3, threads are OK. We expect to make some modifications to the results of the last sprint while we start designing a new feature. But on the other hand, we want everything designed to be tested in the same sprint.
Two good examples of a sprint workload would be:
- a designer would try new copy for the button that failed on last sprint’s usability test and draw a wireframe for the new profile page
- a designer would finish the pixel perfect design for a module and try to solve the usability issue found on a subscription page
Normally, designers will do the ideation and elaboration aspects of the design work themselves. Sometimes, however it is necessary to organize group brainstorming sessions with other members of the product team. The designer’s job is to update the rest of the product team with their progress, and provide them a channel to give feedback.
Thursday—Friday: Research time
When the design is ready, the research begins. This is the heart of the design sprint and we take it very seriously. In fact, in our UX Minimum Checklist, we suggest every product team have at least one user test every week. The findings are integral to the next sprint’s design review and provide essential insights and feedback from the customers.
We believe that a dedicated UX researcher is necessary to the team and to making design sprints work. After all, running weekly user tests in not easy. It’s time consuming to recruit participants, create a test plan, analyze the results, and create reports (not to mention run the tests themselves). If the designer was also responsible for research, her design work would suffer. This time crunch leads to some bad habits, like skipping research entirely.
The researcher’s work doesn’t start on Thursday. During the week, she meets with the designer to collaborate on the tasks and the timing. The design needs and the product type will determine the type of testing. For a new design, the researcher may want to run usability tests with real people from the target group. For products that already have a large audience, she might prefer A/B testing. As I mentioned timing is very important. For example, if the researcher has a test participant scheduled from Thursday at 10am, the wireframes must be ready before that.
Why not have the same cadence as developers?
Some people will suggest that design sprints last 2 or 3 weeks, in order to line up with the developers’ sprints, but I don’t think it is a good idea. Design is usually faster than development, but requires more iterations. The design sprint should be as long as the time it takes to do an iteration, and it shouldn’t depend on outer circumstances. As we wrote in our Agile Design Process Guide, it is okay to have different length of sprints for designers and developers, even in the same team. They just have to be synced. So when the devs have their sprint turns (when they close the previous sprint and plan the following one), designers have that too.
The first steps to start working in design sprints
Now that you know the most important steps, it’s time to get started. Design sprints are easier to practice than most people think.
- Get buy-in from your organization.
- Figure out the core design sprint team: form a designer-researcher pair and get a firm commitment from your business and development teammates.
- Schedule a recurring design meeting for the beginning of the week and make sure your collaborators will be there too.
- At the first meeting, review the current state of the product and choose an easy task to tackle. Be specific: define what will be delivered by the designer, how will it be tested by the researcher, and what the timeline is.
- At the next design meeting, present the design and the research results. Make design decisions together, and plan the next sprint. Talk about what worked and what didn’t work, so the team can learn and improve the sprints.
I hope this article helps more and more design teams to start working in sprints. Please share your experience in the comment section. I’m happy to help if there are any questions.