A design sprint is a way to get a diverse team of people on a project together for a very condensed amount of time to solve a specific problem, such as purchase checkout or product onboarding, in the span of a week.

It gets everyone aligned on the problem and the background and lets teams ideate on solutions very quickly. Most importantly, the sprint wraps up with testing with real users of the proposed solution to validate what works and what still needs work.

A design sprint is not necessarily focused on version one and it’s not designing the entire product; it’s generating solutions around a very specific piece of something that’s high risk and hasn’t been explored before.

You assemble the team on the project comprised of fellow designers, the business lead, engineers, a product owner, a product manager and sometimes subject matter experts who may or may not be directly involved in the project.

Generally speaking you want to keep the team size small, about 6-8 participants. More than that and it can get out of hand and less than that and you may not have all the brains you need in the room.

You’ll always have a facilitator. Sometimes they can be a participant too.

The design sprint is 5 parts.The way that Google Ventures designed it, it’s meant to be five days in five parts. That can be changed to meet the needs of the project.

The goal of Understand is to build the foundation and make sure that all of the work that been done to date in terms of research. Everyone should understand what the business goals and objectives are with any constraints or guardrails for the project. But it’s really just to align who you’re designing for, what the problem and what the opportunity is.

The next stage is Diverge, this is where you start kind of going crazy and do lots of sketching of ideas and come up with lots of different directions and ideas you can go in.

After generating a bevvy of sketches, usually in 2 rounds, you move into the Decide stage. In this stage you take all of those solutions and start making decisions on where you want to focus. You're weeding them out, sometime combining them or adding to them and then storyboard what you actually want to prototype.

The fourth stage is Prototype. Using the storyboards as a guide you build artifacts that you want to test.

The final stage of the sprint is Test where you bring in real live humans and you put these prototypes in front of them and get their reactions and feedback.

I played the role of the notetaker. I bring experience running workshops.

When you run a conventional workshop you want to capture and memorialize what was discussed, making ideas meaningful and actionable by putting them into the context of a project plan. Other times, a workshop is a little more fluid. The role of a notetaker in that situation is to photograph and document everything that goes on so that you can synthesize it and then turn it into something meaningful and have evidence.

In the sprint model it’s very structured and you deliberately create artifacts with the team as you go.

In this particular sprint we had the opportunity to break and the two of us would sit and reflect and change course, based on who was participating and who wasn’t.

The advantage was that the notetaker/ observer could provide feedback about something the facilitator could have missed because she was driving it.

I played the role of facilitator. The facilitator is responsible for driving the activities, keeping time, making sure the team stays on course and facilitating decision making. Sometimes I play both the role of facilitator and participant, but since this was a new team and they had never done design sprints before I wanted to keep us on course. The other thing that was helpful was having Doug give me feedback as the sprint progressed.

Often, it's hard to follow the 5-day model of a design sprint, because getting all of the participants to dedicate a full week of time to the process is difficult. I believe that it is important to get everyone in the room for the first three parts (understand, diverge and decide) and come out of the room with aligned direction on what to prototype and test.

Then, the designers and engineers can go off for a week and design and build a prototype for testing with the group at a later date.

That’s what we did for this recent design sprint; a 3-day commitment to address 2 problems. For the next sprint I’m planning to do understand, diverge and decide all in one day and then move the prototyping and testing outside of the day again.

A lot of times the testing phase is not really about usability tests. We’re not concerned with whether someone really understands all of the directions the screens are telling them or they understand how it works from screen to screen or what the buttons are doing.

The question is: is there desirability for this concept at all? If you are creating a new widget, do people even want this widget? What type of information do they want that widget to contain? What do they want or not want to do with it? When and where do they want that to be available to them? Do they want it on their laptop or phone or on another device?

One of the reasons design sprints are designed to be so quick is because what we build should not be precious. What often happens is the prototypes themselves get thrown in the garbage. We don’t continue to develop those prototypes. What we learn from testing those prototypes informs the next version of the design.

It’s a tool to help make decisions. And to get you out of churn.

When I was having conversations with members of the team everyone had a different understanding of what the project was. The sprint aligned everyone and forced conversations between people. Also, the product and project managers never get to sketch and that allowed them to express the ideas in their heads.

The benefit can be to kickstart things and just get them moving.