A Design Sprint is a process for validating ideas and solving problems by creating quick prototypes and testing them. Created by Google Ventures, it’s a 5 day exercise that will help you to better understand the problem your business is attempting to solve. Your focus will be honed as you sketch out different ideas, run tests, and make informed decisions.

In order to ensure the success of the exercise, we dub someone on the client side the Product Owner. There may be several people involved in decision making at your organization but the PO is the mouthpiece during this engagement. Maybe they’re an executive, or even the CEO, whoever they are, they call the shots. The process is collaborative of course but when push comes to shove, the PO has the final say.

Then there’s the facilitator, they make sure velocity is maintained throughout the sprint. At T R I M we provide an unbiased, trained facilitator who is well versed in the Design Sprint methodology for all of our engagements.

Some additional roles that may or may not be relevant on the client side are Marketing Expert, Customer Service Expert, and Finance Expert. These aren’t mandatory roles, sometimes the PO handles some or all of these, but if they’re available they should definitely be included. The Marketer adds value by being well versed in the company’s messaging, while the Customer Service Expert will know your customers more intimately. And, of course, the Financial Expert will keep the project grounded by weighing the potential ROI throughout the process.

It’s also important to give the folks who will be “doing the do” a seat at the table. We always include a Product Designer and Product Engineer in our Design Sprints. Not only will the ultimately be the ones to bring the result of the Design Sprint to life, their skill sets allow for higher velocity during the exercise itself. Our designers and engineers alike are very capable of prototyping rapidly since they’ve been doing it for so many years.

How to Prepare
Like we said above, this is a 5 day exercise, and we mean 5 full days. We highly recommend you have virtually nothing else going on that week. Phones are also strongly discouraged during the exercise, there will be breaks periodically of course but it’s important that the entire team is focused when we’re actually sprinting.

Whether we’re coming to you or you’re visiting us at T R I M headquarters, there are going to be a lot of sticky notes in the conference room. We’ll be jotting down ideas constantly and sticking them everywhere. A whiteboard will also be necessary so let us know if we should provide one.

Day 1
On the first day we define our long term goals. The fewer the better. Purists would tell you to pick one and only one. The question is, where do you want to be five years from now? What about one year? Six months? That goal will be the true north of the project, everyone involved should always keep it in mind.

Now we turn the goal into action items and hone in on customers’ pain points. This is done by mapping out the user journey based on prior research about the customer. A tool can an Empathy Map can be helpful here and when combined with the user journey, a Swim Lane diagram can be made. This will help illustrate how the user is interfacing with the product and heat map their pain points.

From there we decide which problems can be turned into opportunities, and how. These ideas are voted on by the whole group to determine which problem becomes the focus. The PO gets to decide ultimately but it is still important to vote.

Day 2
Ok, so the problem has been identified, time to throw a bunch of potential solutions at the wall. There are all sorts of different exercises we run to accomplish this. Lightning Demos, Four-Step Sketches, Crazy 8s, and so on. We won’t go into too much detail here, you could probably write a whole article of each of these but the point is that they all encourage and foster rapid ideation. These different exercises provide different levels of fidelity, throughout the day the solution will start to crystalize. By the end of Day 2 the goal is to have a handful of end to end solutions drawn out.

Day 3
Time to prototype. Pick one, and only one of the solutions from Day 2 and prototype it. Like Day 1, this can be done by voting but the PO gets to call it. The goal for the prototype should be good enough quality that it could pass as a real product. We’re faking it at this stage. These are mid to high fidelity mockups that we want to look and feel as real as possible.

The team gets divided into a group of people who make the individual pieces of the prototype, and people who assemble it all into one thing. Usually designers are the ones making the pieces. It is also helpful to have someone dedicated to writing copy. It’s important that all of the text in the prototype is written well enough that it makes sense to the customer. You can also have someone dedicated to pulling assets. Often times, the people making the pieces of the prototype will need an image or an icon in a timely fashion, that’s where the asset sourcer comes in.

Day 4
More prototyping. In our experience, sometimes up to half of Day 3 can be spent deciding which solution to go with. In this case, use Day 4 to continue prototyping. If necessary, Day 4 can be eliminated in some cases. We have done this occasionally if the client is pressed for time or if a solution is decided on and fully prototyped by the end of Day 3. Another task that can be accomplished on Day 4, if not Day 3, is writing the script for the user interviews on Day 5.

Day 5
Testing, testing! Time to get that prototype in front of users. We find that 80% of potential problems with prototypes can be uncovered with as few as 5 users. There are actually diminishing returns beyond that point. The interview script that we wrote early in the week gets put to use on this day. It is crucial that questions are open-ended and do not lead the user in a particular direction, otherwise the data collected will be virtually useless. No more than two team members will test the prototype with users and interview them as to avoid observation bias. The testing is recorded though so that the whole team can review it later in the day.

As the testing results come in, the entire team will help to process them. When reviewing the tests and interviews, the goal is to keep an eye out for recurring patterns in users’ behavior and responses. We then use these themes to roadmap new epics, features, and fixes. Tickets are made in Asana for all of the above, they’re prioritized, and added to the backlog.

With the design sprint concluded and action items identified, now the real fun begins. Time to roll up our sleeves and start designing and building. Design Sprints can be done at any stage of a product’s life cycle. It’s always good to do them early when it’s a greenfield project but don’t let that deter you from doing one well into your company’s maturity. If you’ve got an idea you’d like to validate with a design sprint, give us a shout and hire us to run one for you today.