MVPverse — The Design Sprint Hack
Spoilers — this might have many overlaps with the previous article — MVPverse — The Product Canvas.
Regardless of what literature tells us about the formality of design sprints, for me, it has always been a quick-fire hack to get to your MVP or at least generate an idea of it.
Design thinking is a methodology which provides a solution-based approach to solving problems. It’s extremely useful when used to tackle complex problems that are ill-defined or unknown — because it serves to understand the human needs involved, reframe the problem in human-centric ways, create numerous ideas in brainstorming sessions and adopt a hands-on approach to prototyping and testing.
The design thinking approach was actually started by Stanford’s d.school K12 Lab, where a group of students condensed the identification of problems, generating empathy, brainstorming on ideas, and prototyping them for feedback in one non-linear framework that they called Design Sprint.
Although many mention the 5 stages of the design sprint, I like to have an extra one, you know for the rainy day. To be serious, that extra one is to identify the gap, the problem that you plan to solve, or the vision of the company, Stanford also mentions this as notice.
Six stages of a design sprint
- Notice — Take notice and understand the vision of the company or the product.
- Empathy — The user-centric research. You want to gain an empathic understanding of the problem you are trying to solve. Consult experts to find out more about the area of concern and conduct observations to engage and empathize with your users. You may also want to immerse yourself in your users’ physical environment to gain a deeper, personal understanding of the issues involved — as well as their experiences and motivations.
- Define — User Pain Points and Problem Statement
- User Pain Points — In this step organise the information that you have gathered in the previous step. The best way to do this is to have a list of pain points and evaluate each against the value and risk framework. The value that solving a pain point may deliver to the users and the risk it may pose if not solved. This will quantify your research and will give you a bit of an idea of how to prioritise the user’s paint points.
- Problem Statement — A problem statement is usually one or two sentences to explain the problem your process improvement project will address. Have an umbrella statement that encompasses all of the pain points and ties back to your product vision. Basically answer, based on the user research why should your product exist?
- Template Problem Statement — Existing environment sentence ( In the current market scenario, the users do not have stock information), the problem it is causing sentence ( Due to lack of information the relatively stock market averse users do not complete one month in stock broking platforms even after attractive schemes), what market needs ( the users need a healthy stream of information that are relevant and easy to understand for them to continue in the market).
4. Ideate — Based on the prioritised pain points create ideas, brainstorm on what ideas the users might like and more importantly, what ideas will deliver the largest amount of value. Again as we used a framework in pain points, it is important to use similar in with ideas as well. The best ones if Effort, Value, and Risk.
Effort tells you how big of a solution would it be to adjust your go-to-market. Value lets you know how important the solution is for your users. Risk gives you an idea of solutions or features that you cannot drop.
The best way of evaluating this is teeshirt sizes as we do in story pointing.
5. Prototype — In the next phase, the team based on the prioritised ideas will create prototypes, and light versions that can be tested and gather feedback. The prototype phase is the experimentation phase and is not designed to have the world’s most beautiful products, but ideas that can be tested quickly, without any major risk and can give enough feedback for the team to have better clarity on the actual solution.
6. Test — This testing is dissimilar to user testing, as in a design sprint you focus on the team and stay within. So all of the tests happen within the group. Hence, the low-level prototypes come in handy as they are easily disposable.
The core idea of a design sprint is to gain more knowledge about users, bring the team together and create a feedback loop that can be spread across the entire development cycle.
As per Stanford’s K12 Lab, it should be done within 5 days, so one activity a day should be more than enough.
