In this article, we will cover the why, how, and what of a design sprint, and the special twist that we put on it at Mäd, to ensure we create the best solutions to our clients' business problems.
Why Design Sprints?
The reason for doing design sprints is simple:
Design Sprints ensure that we build better products and solutions, efficiently.
Typically, to learn more about a particular product or solution for a business problem, the iteration process is:
This is already a great improvement on what many traditional businesses do, which is the idea, build, and launch phases, and then fail to analyze what is going well or badly and make changes.
However, this is a very intensive process which can take months or years before a product is built and launched, and so a design sprint can be used to verify an idea and learn from the idea while skipping the build and launch phases.
This has the advantage that key learning points can be gained in days or weeks instead of months and years, and, of course, it is significantly less expensive and risky.
Essentially, you fast-forward into the future and see how the product or service could work and how customers would react to it, without the full journey to build the entire thing.
So the key idea here is to try and validate ideas, learn, and then eventually apply these ideas to build a product that people will actually use or a solution that will actually solve the business problems that have been defined.
Often, especially for large businesses, the constraints are not time and money, but building completely the wrong thing that adds zero value to both the business and the end users.
How It Works.
A typical design sprint follows a five-day schedule, where each day focusses on a complete part of the journey towards creating and testing a prototype.
- Monday - We map out the problem and pick an important place to focus.
- Tuesday - We sketch competing solutions on paper.
- Wednesday - We make decisions and turn the ideas into a testable hypothesis.
- Thursday - We hammer out a high-fidelity prototype
- Friday - Test with real life human beings (yes, the ones that don't always tell you what you want to hear!).
Let's dig a little deeper into each stage.
1. Journey Mapping
Essentially at this point we ask ourselves what are the goals that we want to achieve, and how are we doing do this?
- How are users discovering the product?
- What do they have to learn?
- What is required for them to use the product?
2. Solution Sketching
We choose focus points on the map and build high-level solutions to vote on.
3. Testable Hypothesis
We focus on building a solution on a particular point that will actually be tested with real life users.
We build something that we can test with users!
- We test! See Usability Testing
Our Twists - Mäd Design Sprint
Based on our real-life experience, we've made some changes to the typical design sprint process and have aptly named it "The Mäd Design Sprint".
This is actually one part of our larger design process:
- User Empathy - Where we listen to existing or potential users with the target to understand their pain points right now, what's their everyday journey, and then we create one to tree personas to describe key user behaviour.
- Define - We filter all the feedback, information, and data that we received during the User Empathy stage, and we build an affinity map. This means categorizing all the feedback into meaningful groupings, so then we can solve a particular category of problems.
- Ideate - One of problem categories is chosen to be solved, and we do brand writing together with the client to further define the problem and ideate possible solutions.
- Prototype - Based on the most voted solution by key stakeholders, we build a rapid interactive prototype.
- Test - We go out and meet with the target user group and do usability testing.
- Design - Once the test results are back in, we design solutions based on the users' feedback and solution prototype that was chosen.
Our design sprint tackles points 2 to 5 of this process.
Our change is that we only do four day sprints instead of 5 (Fridays are for Mäd Fridays, internal work, and beer). We achieve this by compressing the Monday and Tuesday schedules (problem mapping & solution sketcing) into one day instead of two.
So our schedule looks like:
- Monday - Journey mapping & solution sketching.
- Tuesday - Testable hypothesis.
- Wednesday - Prototype creation.
- Thursday - Testing.
We also only invite clients to work from our offices on Mondays and Tuesday, as we tend to see that they have very busy schedules, and also that we can work on the prototyping and testing by ourselves without client involvement, and still get great results.
Design sprints are a great tool to ensure that we can solve real-world problems in days that would normally take months, and ensure that we can build successful products everytime.