Running a design sprint is an effective way to solve a problem, create a new product, or improve an existing one. However, your pre-sprint preparation can determine whether the sprint will go the distance or fizzle halfway.
One of the things you’ll need to prepare is a good design sprint brief. A design sprint brief is a high-level document that outlines the main problem the sprint is trying to solve, the current scenario, and supporting data from research. It may include the sprint goals, the agenda, and other details that are relevant for the sprint’s participants. A brief gets everyone aligned on the objective, understands their roles, and is focused on the desired outputs, so the sprint can be productive and effective.
In this article, I’m going to list the things you need in a design sprint brief, what to exclude, and a few tips for crafting an impactful brief. Before that, if you’re new to design sprints, do check out my previous post on the top 15 FAQs for running your first design sprint.
What you need to do to create a design sprint brief
1. Do your research
The first thing you need to do is to understand the current challenge or problem that’s plaguing the product. Gather as much relevant information and data as possible to establish the product goals, users, competitors, and the market. You’ll also need to study recent user feedback, product metrics, and other relevant data points.
You can speak to key stakeholders to gain more insight into the broader business perspective, including business goals and constraints. Understanding the history of how the product got to where it is today will also help in sharpening the focus of your sprint, so you’re not wasting time discussing or doing something that has been done before.
2. Find your sprint’s big picture
A design sprint needs a problem worth solving.
After all the background work has been done, you need to decide on the big question you are finding answers to. Logically, it should be a problem that will offer the biggest positive impact when it is solved. If the problem is complex, then you can dissect it into parts and attempt to solve it over several sprints. Examples of problems worth solving are: testing a new product idea, redesigning an existing product to cater to a new market, or integrating several products to make it more seamless for your users.
It’s worth highlighting that a problem doesn’t have to be related to a product. You can use a design sprint to solve business-related issues such as finding clarity in your business strategies, prioritising business goals, or aligning teams and workflows.
3. Define the sprint’s scope and constraints
After you have identified the big question for your sprint, define it with a problem statement. A problem statement should be clear, specific, and user-centric.
Based on a problem statement, you can then define the scope of the problem, the objectives, and the constraints that come with it. Defining a scope ensures that your sprint doesn’t deviate from its original intention, while an objective helps you track the success of your sprint. Meanwhile, identifying existing budget, resource, technology, market, and time constraints keeps your solution realistic and feasible.
Once you have established all these parameters, the purpose and the direction of your design sprint become clearer, and your design sprint brief is more than half done.
What to include in a design sprint brief
A design sprint brief lays the foundation for a successful sprint. Your brief needs to be clear, concise, and written for a wide audience as it will likely be shared with different teams and stakeholders, from design and engineering to business stakeholders. Do check out this example of a design sprint brief to give you a better idea. Your design sprint brief should include:
1. Problem statement, objectives, and scope
This is where you clearly define the specific challenge you’re trying to solve that is relevant and critical to your business.
Outline the sprint’s objectives, and the scope of the problem you are solving. Don’t forget to list the constraints and previous obstacles in terms of budget, resourcing, or timeline that provide more context to the problem.
2. Background research and insights
Identify the end users, user needs, user behaviours, and other insights on the target audience and market.
Add in any relevant research, metrics, product data, and user feedback that can better inform the sprint participants on the problem in hand. You can include any past learnings and project history for better context. This gives a complete picture of the product’s strengths and weaknesses, as well as past initiatives that worked or didn’t work.
3. Key visuals
It’s important to include visuals to help people easily understand the problem they are trying to solve. Some examples are images and videos for user personas, customer journey maps, product strategy and roadmaps, product architecture, and product metric charts.
4. Sprint output and success metrics
Define what you want out of the sprint. This is an output such as a user-tested prototype, an MVP design, product strategy, product roadmap, or business process alignment initiatives that moves your business or team forward. If applicable, you can identify a handful of metrics, such as conversion rate or user satisfaction rate, that serve as a long-term yardstick for how effective your sprints are.
5. Sprint agenda and participants
Make a list of the relevant people who should be in the design sprint, including their roles and responsibilities. This ensures everyone who isn’t already acquainted, knows who they will be working with in the sprint.
Outline the sprint’s agenda for each day. It is helpful to include a brief explanation of what each session is and its objectives for people who have never participated in a design sprint. You should also list any preparations that participants are required to make or items they need to bring.
Tips for Writing an Effective Design Sprint Brief
Don’t put in ambiguous information
Write in the simplest way that can get the message across by utilising clear and straightforward language. You should avoid confusing objectives and problem statements. Be specific, direct, and include relevant information that educates your participants.
Avoid excessive detail
Your design sprint brief shouldn’t have so much detail that it makes it hard for participants to see the challenge for what it is. While you should include background research, it’s wise to write summaries of past research and current data instead. Leave out in-depth technical details for the actual design and development work that takes place after the sprint.
Collaborate early with stakeholders
Collaborating early with relevant stakeholders for the sprint will help you collect a diverse set of opinions and data, which makes for a more fruitful sprint. There have been occasions where I’ve had to run a short workshop prior to a sprint, when the product and business are complex with many parties involved. Early alignment also prevents misunderstandings and miscommunication later during the sprint.
Focus on the problem at hand
Every sprint is anchored in a big challenge it needs to solve. Always focus on the challenge in hand and write from that perspective. If it is a product challenge, think and write from the user perspective. You’re trying to solve a problem or meet a user need, so the user needs to be at the forefront when crafting a design sprint brief.
Review and adjust your design sprint brief
Get someone to review your brief to make sure it’s clear, well-structured, and well-informed. Allow some flexibility in your brief because a sprint can sometimes uncover a new opportunity or pinpoint a blind spot, so keep this in mind when writing the brief.
