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.
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.
Drop us a message if you need any helps from the DwarvesLet's build