So, you’ve decided to give design sprints a try, well done! You’ve spent five-or-so days intensely focusing on a specific problem. You’ve been lucky to get useful, direct, and hopefully positive user feedback on your prototype. Now you’re wondering what to do with all this feedback you collected and how to turn it into a successful product.Depending on your work style, design sprints might fit into development in a different way:
Obviously, design sprints don’t happen in a void. You need to find out how to feed the design sprint outcomes back to your development team. To implement the outcomes, you might want to try these things:
By following these points, you will keep a holistic view of your business goal, increase productivity, and ensure that you deliver the right set of features to your users. In this article, we’ll look into some tips on how to do just that - complete with design sprint examples!
Having all these outcomes from the sprint might feel overwhelming. You need to somehow make sense of them. The best thing is to put your design sprint outcomes into a broader perspective, to make sense of the existing and new knowledge. This is important since one of the design sprint results is not only the prototype itself but also the alignment between team members on what is valuable.Think about the following things:
Let’s look at the invoicing app prototype as an example:
We wanted to learn how users might use the mobile application to issue invoices for their clients. The sprint provided us the validation that invoicing on the go is a necessity, but it’s also hard for users to type all the required information on the go. This opened a question of whether there is a need for the web application, to enable easier data entry.
The design sprint outcome might sometimes feel overwhelming and closed in on itself. Because of that, it’s important to break the solution down into meaningful chunks and decide what should come first. You can do this collaboratively, based on your team’s input. Now is the time to ask yourself:
Let’s look at our invoicing app prototype again. The ideas that ended up being a part of the design sprint prototype were high-level and didn’t cover the whole user journey. This meant that we had to work a bit more on covering different cases. For example:
With all of these new ideas collected, it was time to prioritize them. There are a couple of prioritization techniques that I found helpful in deciding what will actually get built. Let’s go over them below, by looking at an invoicing app prototype as an example.
User Story Mapping is a tool for backlog visualization, introduced by Jeff Patton. It fosters a shared understanding of what you want to build and why, and it does so by displaying stories as part of user workflow.
How can you use it? By now, you have the overarching goal defined by your design sprint. You can use the user journey you defined during the sprint as your story backbone for the story mapping. The backbone is essentially an end-to-end list of high-level user journey steps - a timeline. Next, you'd want to identify activities that group user journey steps, and then break the journey steps down into tasks and sub-tasks. To do that, look at constraints and edge cases, different user roles, or any product details that are specific to your business case. The last step is to decide how to group tasks and subtasks into releases.
You can find some great guides on how to do user story mapping here and here, and of course - there’s a book on it.
Prioritization Matrix is probably one of the simplest and most effective prioritization techniques out there. The tool is also known as the Eisenhower Matrix, and it helps to rate tasks based on urgency and importance. An alternative version - focusing on informing UX decisions. It allows you to map out features according to user value and development effort. The quadrants then tell you:
How can you use it? Make a matrix on a whiteboard where X-axis is showing high to low effort and Y-axis showing low to high user value. Then place your ideas where you think they belong, by asking questions like:
In my view, Prioritization Matrix is especially nice when combined with user story mapping (a.k.a if you’re not sure how to bundle your releases). That's because it will make you think about what’s the user value versus effort to develop something.Tasks ranked using the Prioritization matrix. The ones with the lowest effort and highest user value (in the upper right quadrant) should get to the development first.
The New, Useful, and Feasible Test is a simple matrix that can help you prioritize numerous ideas by rating them and adding up their scores. In the end, you get your ideas ranked by the overall score.How can you use it? List all your feature ideas on the left, and add the New, Useful, and Feasible columns to the right. Then validate each idea from 0-10 based on:
After summing up the scores, the ones with the highest value should become your team’s priority.
After the design sprint and prioritization in place, it’s time for one last prototype checkup with the users. The design team can add more in-depth interactions that reflect the scope you prioritized and run the updated prototype by users to make sure all is clear.
For our invoicing application, this meant we had to design the onboarding experience and detailed interactions for the account settings. With these improvements in place, we ran the prototype once more by the users.
With this completed, it’s time for development. Of course, you’re not done there - you’d want to track what happens in the wild once you deploy your solution to users. You can collect qualitative (a.k.a analytics) and quantitative (a.k.a customer feedback) data and use it as a basis for your next steps and deployment phases.
The end of a design sprint is really the start of product or feature development, and the learning never stops. Once you get the hang of prioritizing and getting user feedback on the things you’ve shipped, you’ll be able to adjust the scope of any new iteration of your product, based on user needs. This will result in your team being more productive and keeping an eye only on what matters. Prioritization requires you to combine your business knowledge as well as new findings from the design sprint. It can also change with the new feedback after your product is live. The key is that you’re able to react quickly to it.
If you're feeling generous why not spread the words on Twitter.
You’re done with your . Now what? 🤷🏻♀️ What comes after your sprint is as important as the outcome you get out of it.
Have a good one!
