• marijastupar

What To Do After A Design Sprint?






Discover prioritization techniques for turning your design prototype into a product.


Introduction


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:

  • You might have a dual-track sprint (a.k.a mini-waterfall), where design is usually one sprint ahead of development.

  • You might have design spikes as part of your agile sprints, where your whole cross-functional team is able to focus on one problem for a period of time.

  • You might have a more relaxed Kanban workflow, with design sprints done when needed.


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:

  1. Combining outcomes with previous knowledge

  2. Prioritizing and breaking things down

  3. Revalidating and tracking success


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 examples!


Combine outcomes with previous knowledge


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:

  • What are the main points that you have learned in a design sprint?

  • How do these points reflect the current state of your solution?

  • What has been validated?

  • What needs to change?

  • Are there any assumptions that still need to be clarified?

  • Is the business case affected by the learning points?


Let’s look at the invoicing app prototype as an example.


Wireframes exploring the invoicing app idea


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.


Prioritize well and break it down


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:

  • What are the edge cases that the design sprint didn’t consider?

  • What user actions are available through the prototype?

  • Which of these actions are crucial to ensure an end-to-end user journey?


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:

  • We were missing the whole onboarding flow, so we had to define it since it was a crucial part of the journey.

  • We didn’t think through all the account settings options such as invoicing templates or security options. It turned out that some of these were important to users.


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


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.



User Story Mapping used to break down invoicing steps. The tasks with higher perceived business value become part of the MVP release.


Prioritization Matrix


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:

  • what you should absolutely focus on,

  • what you should maybe focus on, and

  • what you can probably leave behind.


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:

  • How valuable is this feature for our users?

  • How complex is this feature to build, and how much time would it take us to build it?


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 NUF Test


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:

  • How new is it - is it already seen in your product or a completely new idea?

  • How useful is it - how much value would it bring to the users or business?

  • How feasible is it - is it possible to develop within the timeframe and constraints you have?


After summing up the scores, the ones with the highest value should become your team’s priority.




NUF Test prioritization outcome. Ideas can be easily ranked by total score.


Revalidate, develop, and track success

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.


In conclusion


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.



That's all folks


If you're feeling generous why not spread the words on Twitter.


Have a good one!




Join our 400+ growth hackers and get

practical tips right into your inbox













Need to build a business for impact?