Once you’ve understood a problem, ideated, and created a solution, you then bring the idea through to a concept design, for user validation. If the idea resonates well, you create a spec to hand off to engineering. Using design thinking to diverge and explore ideas before ultimately focusing in and converging on a single idea. Once you have that idea you’ll map out the full concept and create a prototype, which can then be used to validate that you’re solving a real problem for real users.
You can see where this process sits within the entire product to market process:
What is design thinking?
Human centred approach, focused around solving problems by really understanding the user and their goals on a deep level. At the same time, you’ll be challenging assumptions about what you know and redefining problems to identify new solutions. There are a handful of design thinking methods to help achieve these goals.
Human centred means there’s a focus on deeply understanding users and their needs and then going through a process of redefining problems, creating solutions testing them with real users.
What is a design sprint?
A design sprint is a time constrained process that uses design thinking with the aim of reducing the risk when bringing a new product, service or feature to the market.
Once you’ve identified a specific challenge that you need to solve, it mat seem like a simple problem. But more often, when you start to look closer, you realise that there’s a lot of different factors that you need to understand and consider before reaching a solution.
Design sprints can be used to solve a wide range of problems, from solving user needs through the creation of a new product, like an app to measure and track your fitness, to adding new functionality to an existing product, like the ability to sell shoes through the fitness tracking app.
A design sprint happens when you bring together a cross-functional team to solve a specific problem in a set amount of time. During a design sprint, you will explore and prototype solutions and then test them with real users. Through the entire design sprint, you will use design thinking methods that are specific for each phase of this sprint. Design sprints are a powerful problem-solving tool when you’re faced with difficult questions and you’re unsure which direction to go.
But design sprints aren’t just for new things. You can also use design sprints to resolve issues with existing products. For example, why do users stop using that fitness app after one month? Or how can we solve the issues that’s causing 10% of the fitness app users to context support each month?
A week of exploration, prototyping, & testing
Design sprints involves stretching your understanding of a problem, thinking about it from different perspectives, and then brainstorming solutions, ultimately picking one idea, building a prototype, and then testing it with real users.
Design Sprints are highly customisable
Design sprints generally follow the same set of phases but those phases are highly customisable to adapt to the specific challenge that’s being tackled. Most design sprints usually take about five days to complete although it is possible to complete a Design Sprint in a shorter amount of time depending on the scope of the problem.
Team members participating in the sprint should be team members who are responsible for building and launching the solution.
Always include someone from Product Design
Always include someone from Engineering
Deign sprints are highly collaborative and so including key team members is a great strategy to help create buy-in as well as a sense of ownership as everyone comes together as a team to solve a problem.
Design Sprints de-risk bringing a new idea to market
A huge benefit of a design sprint is that it allows the team to explore and learn without actually having to build or launch anything. This is one of the most important benefits of design sprints. It allows you to take about a week with a team exploring a problem, finding a solution, and validating it.
If everything goes smoothly the team will have clarity around exactly what needs to be built. But in the worst case scenario, the team fails early and lead that their solution isn’t viable. If the team hadn’t gone through a design sprint and just started building their product, they might have spent months or even a year before they’re able to get feedback the the product is not going to be successful.
In some cases, you’ll come to the conclusion that there is something there but you need to spend more time developing the idea and concept potentially in another Design Sprint. In other cases, you might realise that there’s something there but it’s not actually the right time to pursue that idea.
How does a Design Sprint work?
There are six phases of a Design Sprint. The first two are really about understanding the problem. The next two phases are about coming up with a ton of different possible solutions and then narrowing in and picking one, and the last two phases are about building out and testing that one idea.
You’ll notice, below, that the phases go through a pattern of diverging and expanding to make sure you’re exploring all the aspects and pushing your thinking, and then converging and narrowing to focus on the specifics.
Understand – create a shared understanding of the problem space, the user, the competition, and why all this matters.
Define – focus on where you want to end up. Often easier to work backwards to understand what needs to happen in order for you to get there.
Sketch – brainstorm, ideate, and diverge to explore a ton of different solutions.
Decide – bring it all together and decide on one idea to bring through the remainder of the sprint.
Prototype – take your idea and map it out in more detail. Start with a storyboard and turn it into a prototype.
Validate – put it in front of real users to make sure your idea solves a real user need. This is a good time to have a technical feasibility conversation with the engineering team to make sure that its not just a good idea, but that it can be built in a reasonable amount of time.
Design Sprint Outcomes
Before you start a Design Sprint it’s good practice to plan what the best steps afterward will be. But it’s also important to acknowledge and respond appropriately based on the outcome of what happens during the sprint.
At the end of the Design Sprint, you’ll have tons of artefacts including:
Insights – from the understanding phase when you explore the problem space, as well as user validation when you start talking to users to get their feedback about your idea.
Ideas – tons of other ideas from the brainstorming and sketching phased that can be explored at a later date.
Prototype – a working prototype of your concept
So what happens after a design sprint?
What happens after a Design Sprint really depends, but here are some possibilities:
Build it! – everything went really well and you’ve got the validation that your idea is on track and all the pieces are ready to go, and it’s time to build it.
More design time needed – maybe the idea resonated well with users, but it’s not super polished yet and design needs to spend a little more time on building out the UI.
More iteration and testing needed – there’s something there with the idea, but it’s not quite ready and you need to spend more time iterating and retesting before moving on.
Leadership buy in needed to invest more resources – there’s something there but it’s actually going to be a much bigger project than originally expected.
Concept abandoned because it doesn’t address user needs – no go and the idea didn’t adequately address user needs.
Who should participate in a Design Sprint?
Even though it’s called a Design Sprint it’s not just for designers. The best Design Sprints occur when there is good representation across a number of different functions. There’s a lot of value in bringing together a group of people who have different perspectives, different background, and different areas of expertise. The people who are actually building the product need to be involved. Generally, this means that product design and engineering should always be included in a design sprint.
The largest factor that will impact who you wanted to participate in a design sprint is highly dependent on the specific challenge the sprint is trying to address. You should identify individuals who can bring perspective, expertise, and value.
You’ll always want to have product, design and engineering involved because these are the people who are going to build the actual product. For a new product it’s often helpful to include some from leadership. This might be the executive sponsor for the project. Additionally, it will be helpful to include someone from research and marketing who are familiar with the space and your users.
New Product Concept
Enhancements for product
For enhancing an existing product, for example with a new feature, it might not be necessary to include leadership.
Fixing a problem with a current product
In terms of addressing an issue with a current product, in addition to product, design and engineering, it’s helpful to include someone from support who understands the issue and how users encounter it as well as how the issue is currently being resolved. It can also beneficial to include a researcher who’s familiar with the target user and the product flows.
Optimising a current product
For optimising a current product, in addition to product, design and engineering, it’s helpful to include someone from data science who understands where users might be dropping off and why. Again, it can be helpful to include a researcher who’s familiar with the product.
These are just suggestions. When picking your sprint team, you’ll want to make sure you’re bring together a group of diverse perspectives that can tackle the problem. That’s the most important thing.
The best Design Sprints occur when there is good representation across a number of different functions:
Product
Design
Engineering
Researchers
Data Scientists
Marketing
Leadership
Support
Opperations
Sales
Privacy & Legal
Finance
Is it the right problem?
Design Sprints are great at a lot of things. They bring together a team to focus on solving a problem in depth. They’re best suited when there’s big open questions. However, they don’t work as well when a solution are in depth directions have been identified.
Some problems are a good fit for Design Sprints and some are a bad fit.
Good Fit
New Product
New feature for existing product
Improvement to existing product
Solving a complex problem – during the process you’ll map out all the pieces and have much more clarity by the end of the sprint.
Bad Fit
There’s a clear product definition, but no final designs
There’s not enough foundational research to understand user needs
All ready have an answer
Planning a design sprint
During a Design Sprint, there’s an important role called the Sprint Master. This is the person who runs and facilities the sprint.
What does a Sprint Master do?
Creates the structure of the sprint – includes the schedule, creating the right context for the people participating in the sprint.
Selects which methodologies the team will use during and make sure the team is set up to get the right outcome from each exercise.
Facilitates bring the sprint by guiding the team through all the various activities.
Keeps the team focused and on schedule as well as re-focusing the team if they get off track, or re-framing if the team gets stuck.
Challenge statement
A challenge statement tells us the action that you will be doing, the output of what you will be building, for a user that will be using it, to solve problem for our users and in a certain timeframe.
[ACTION] + [OUTPUT] + FOR [USER] + TO [SOLVE PROBLEM] + BY [TIMEFRAME]
Design an app for consumers who do grocery shopping to make it easier to purchase items by next year.
Working with new teams
Each team member should introduce themselves and share their superpower that they bring to the Sprint team
Working with designers
There’s a ton of overlap between product managers and designers, and they’re one of your most important partners. Both Product Managers and Designers care about building great experiences that solve a real need for users. But there are some differences. At a high level the role of a product manager is to frame a problem and set the direction of the solution. But it’s up to the design team to create the actual user interface and experience. It’s important to acknowledge this.
At times there is likely to be tension between Product Managers trying to get everything launched and out the door on time, and design wanting to make sure that we do the right thing for the use, and these types of moments it’s important to understand where each perspective is coming from.
Product Manger vs Designer
Product Manger
Sets priorities for the team
Responsible for business outcomes
Manages stakeholders and communicates across larger teams
Deeply understands users and defines use cases
Participates in / conducts user research & usability testing
Designer
Owns visuals and interaction design
Owns information architecture
Creates mocks and prototypes
Deeply understands users and defines use cases
Participates in / conducts user research & usability testing
It is helpful to acknowledge that you are not a designer. You are a Product Manager. Acknowledge that the designers have expertise when it comes to talking about user interfaces and flows. When critiquing a design it’s often more effective to ask about the intention of a choice, rather than saying you don’t like something.
🤬 It makes no sense that the “Continue” button is placed in the bottom right-hand corner.
😡 I don’t like where the “Continue” button is placed.
🧐 How did you decide to put the “Continue” button in the bottom right-hand corner?
🤩 I’m worried that users might be confused and not able to find the “Continue” button because it’s placed in the bottom right-hand corner – This helps the designer to understand why you are concerned. But also that the design might prevent users from completing their goal.
