Any company that has created a product in the digital sphere will no doubt be familiar with the purpose of Design sprints. Traditionally both back end and front end developers, designers, marketing teams and other stakeholders in the company come together over the course of 5 days with the purpose of prototyping ideas, gathering insights on users, and validating them before building solutions with company resources. Like most start-ups we are always extremely busy and getting people to work for 5 days felt like a lot, even 2 days was a stretch for some so we decided to see if we could come up with a way to get the same results in a fraction of the time.
First off, traditionally the design sprint is held over 5 key days to help
- Understand – Map a challenge and particular focus area
- Ideate – Come up with many design solutions
- Decide – Turn those design solutions into a storyboard
- Prototype – Create a prototype based on those storyboards
- Test – See how users interact with the prototype, and learn in order to iterate further
For our design sprint this time, we wanted to test another approach for the first 3 steps in the process (understanding, ideating, and deciding). Instead of taking 3 days to complete the majority of the design sprint, we wanted to test if we could deliver similar results in 4 hours. We did, handing off storyboards to our designer for testing and iterating with live users. This cut a normal 5-day design sprint in half. This is how we did it.
The Purpose of Our Design Sprint
We were creating a top secret brand new feature we wanted to add to our product that required the design sprint in the first place. At Usersnap, as a customer feedback company, it is probably unsurprising to hear that first and foremost we use our product to collect feedback from people using our products and we do extensive research on that feedback, and take our findings directly to a design sprint for ideation and prototyping.
Preparation is Key
If you want to cut your design sprint in half, make sure you have the following in advance:
- Research on our target personas (we conducted 20 interviews and collected 130 survey responses)
- A clearly defined and agreed upon challenge for your design sprint team to tackle
- The deliverables at the end of the session
Desired outcome: Make sure everyone is clear and aligned on the challenge to tackle.
You may wonder: “Why would you prepare these things beforehand when all of this could be discussed during the design sprint?”
We wanted to:
- Give people time to sit with the challenge and have ideas to present during the design sprint
- Save time just getting everyone up to speed
Understand (1 hour)
Instead of a full day to understand the challenge, we used 1 hour. How is this possible? Importantly, our participants came prepared in advance, and our in-house researchers had extensively analyzed the findings from our research stage.
Presentations (15 minutes)
First, each expert presented the findings of our target persona and their pain points. There were 3 researchers who each had 5 minutes to present the qualitative, quantitative, and nuanced aspects of the persona’s pain points. With a short period of time, our researchers were forced to focus on the most important problems of our persona.
While presenting, the other participants wrote down “How Might We’s” (HMWs) on post-it notes. HMWs frame challenges in question form, and these post-it notes are integral to the ideation stage.
Desired outcome: Understand the persona of the chosen design sprint challenge.
Expert Interviews (45 minutes)
Second, researchers were interviewed by the participants to learn more about the persona’s challenges. Importantly, set the timer for 15 minutes for each researcher, and fire away questions.
Desired outcome: Expand on particular points that participants wanted to know more about.
While Q&A continues, respondents continued writing HMWs on post-it notes.
Ideate (1.5 hours) and Decide (1.25 hours)
Ideation and decision takes 2 days in total according to the design sprint manual, and we gave ourselves less than 3 hours.
Problems Worth Solving (30 minutes)
First, we set the timer for 3 minutes, and all of us came up with our top 3 HMWs to put on the wall. When time expired, we presented our HMWs, and placed them on the wall in order of our persona’s job steps. If a HMW is repeated, either replace it because it’s more relevant or throw it away.
From there, we all received 3 stickers, set the timer for 3 more minutes, and proceeded to vote on which 3 HMWs were most relevant to the persona’s pain points. The voting is not meant to eliminate less relevant HMWs, but to clarify what the group thinks is most important.
Crazy 8s (1 hour)
Second, we did 2 rounds of crazy 8s. At this point, we were breezing along, and even my own expectations were exceeded: we were getting close to designing something in a fraction of the time it normally takes!
The steps to crazy 8s are simple:
- Take a large piece of paper, and fold it into 8 parts (“tiles”)
- Set the timer for 8 minutes, and begin
- Provide up to 8 screen designs based on any of the HMWs written down (which made it to the wall or not)
- Less than 8 screen designs? No problem
- Want to present a flow with multiple tiles? Go for it
- When the 8 minutes are up, place each piece of paper on the wall
- Present 3 of your 8 ideas to the group, and explain what problem the design should solve
- Repeat the process a 2nd time, combine ideas from others or expand on them
Decide (1.25 hours)
Storyboards (1 hour; then 15 minutes)
Third, we broke up the design sprint team into 2 groups, making sure there weren’t too many participants with substantial design sprint experience in a group.
We set the timer for 1 hour, and each group came up with a storyboard flow with 5 sheets of paper. We didn’t give clear guidance on how to design the storyboard, but it should represent 5 key steps to reach a goal. If both groups approach the problem in the same way, it gives good insights into the nuances of the problem. If each group approaches the problem differently, it provides perspective to the problem itself.
Fourth and finally, we presented our storyboards. Each group has 5 minutes (set your timers!), and time for quick Q&A afterward.
Retrospective (15 minutes)
Finally, it was time to conduct a quick retrospective. Each participant had 3 minutes to provide their thoughts:
- What did you like?
- What didn’t you like?
- What could we improve?
- Any additional comments?
Handover for Prototyping and Testing
From there, we handed the HMWs, crazy 8s solutions, and storyboards to our designer to develop a prototype, do user testing, and iterate on the design. From previous prototypes, we knew that we would hear a lot of the same feedback from the participants. So we decided to change relevant and obvious flows right away, and test an already modified version with the next participant. This process allowed us to achieve a more relevant flow in a shorter time.
In the end, none of this is possible without customer research. It was the foundation of our design sprint, and we used our own product in order to collect feedback and organize it in a way that gave us sound insights leading up to our design sprint.
Those 4 hours yielded great results for the type of challenge we wanted to solve, and we didn’t use 3 days to get there. It took us longer to get to a tested prototype, but only 1 or 2 people were involved, and they didn’t dedicate 100% of their time to the prototype iteration. This process fit better to our day-to-day schedule.
We found the process very helpful and will do it again, always re-evaluating where we can improve. For anyone who would try this method:
- Be sharp and clear on the goal
- Have well-prepared participants
- Keep your timers handy
- Question the quality of your results
- Let us know if we’re onto something
Go to Source
Author: Haymo Meran
Powered by WPeMatico