Design Sprint

We use Design Sprint to validate ideas and solve problems. It's an intensive 5-day framework designed to iterate through decisions and test different alternatives.

A Design Sprint can have the following outcomes:
An efficient failure: The prototypes didn’t hit the mark, but you learned something (or many things) and saved your team four to six months of work building the wrong product. You might want to run a follow-up Sprint.
A flawed success: Some ideas met your user’s needs, but not all of them. You learned something and can now iterate and test again.
An epic win: The concept met your user’s needs; they were able to complete tasks easily and engaged with all the features you mapped out. You are ready to implement!

Day 1: Understand the problem
By doing mini sprints with the client, we already grab the context & insight from the client, define Problem & Value Proposition then figured out the solutions with User Stories & Paper sketch. Day 1 in Design Sprint, we lock down on which problems will be solved this sprint.

  • Start at the end, set the bar for the product. Think of a "happy case" for the product a few years from now. This helps us set goals for the products. Now we visualize what the user experience might look like. Create a basic map for the project which shows how users will go through your product or service. Keep it simple - 5-10 steps max. List user personas on the left side and the end goal on the right side of the map. Personas reach the desired end goal in around 5 to 10 steps.
  • Ask the experts, get input from them so we can improve our previous map. Here we should have people who are experts on some of the problem in a room and ask for their opinions. Use the “How might we…?” technique. While your team members listen to the expert’s interviews, ask them to take notes. Each team member should take notes in the form of a question, beginning with the words “How might we…” This technique ensures all notes have a similar format and makes it easier to organize, read, and evaluate them.

Day 2: Sketch
Day 2 is all about solutions. During this phase, we visualize our solutions with paper sketching. Sketching allows us to go from abstract idea to something concrete that everyone can evaluate. Some of the sketches we create on 2nd day will be the building blocks of the prototype we’re going to build on 4th day and test on 5th day.

During the 2nd day, we can also start with Lightning demos, an exercise allowing us to review great solutions from other companies. Often, great ideas have been pitched in the past, and all we need to do is to find the one that fits your purpose.

Day 3: Decide
When we get to day 3, we already have on hand many solutions sketched up. Now we need to decide on one best-fitted solution and turn that it into a prototype. Decision making process being with everyone in the team vote for one solution of their choice. Chances are there might be more than one winning solutions (equal votes) - in such cases, we’ll need to build a few prototypes.

After the vote, the winning solution gets carefully storyboarded in greater details, frame-by-frame for the prototype. At the end of the day, a storyboard should be as complete as possible. It’s essential to fill in all the missing pieces before moving to prototyping (if someone in our team asks “What happens next?” when reading the storyboard it’s clear sign some frames are missing).

Day 4: Prototype
Prototyping is a culmination of all the work a team did so far in terms of creating a solution. Storyboards that our team created in the previous stage can be easily converted into a prototype.

Creating a prototype in just one day can sound unrealistic because normally the process of prototyping would take weeks. However, an important thing to remember when prototyping is that we’re not building a fully-functioning product — we’re creating something that allows us to get the feedback from the users. This means we don’t need to code anything, all we need to do is to build a realistic facade — something we can put in front of the users/stakeholders to get their reactions. Think about the absolute minimum that will give the users an accurate representation of the idea so they can provide feedback.

4th day ends with a trial run between the team itself.

Day 5: Validate
The validation stage answers the most critical question in product design — “How do I know if my work is any good?” During this phase, we test our prototype with real live users. We show a user the prototype we’ve built and watch their reactions.
During the interview sessions, we should look for patterns. Eventually, we’ll find parts that work successfully for all test participants and parts that didn’t work as well as expected (places where users were confused or weren’t interested).
At the end of the validation phase we should feel confident in what you validated and, if validation was successful, move to the next solutions on the list.

We’d love to work with you.

Drop us a message if you’d like to build with the Dwarves.

Let’s build