Effective Design Sprint: Goals, Processes, Steps and Methods

A design sprint is a time-bound process with five phases typically spread out over five full, eight-hour days.

The goal of design sprints is to solve a critical design challenge through designing, prototyping, and testing ideas with users.

A design sprint can answer critical business questions to design challenges. We use design sprints to answer questions, define product directions, figure out cross-team strategies, and even build team culture.

Before launching into a design sprint, you need to review your design challenge and ask yourself these key questions:

• Are there any potential solutions to your design challenge?
• Does a design challenge require people from cross-functional teams to weigh in?
• Is the design challenge’s scope wide enough for a sprint?

Design sprints generally include five phases: Understand, Ideate, Decide, Prototype, and Test.

A traditional design sprint lasts five days, with each phase taking up to one full day. Creative collaboration is at the core of every phase.

1. Understand: Map out the problem and pick an important area to focus. Sets your sprint on the right track and helps your team get a clear picture of the design challenge. Your team takes time to learn from experts and engage in creative discussions with a lot of different people from other departments and industries.

• What is the long term goal? Why are we doing this project? Where do we want to be six months, a year or even five years from now?
• It’s important to turn the goal into actionable items by rephrasing your assumptions and obstacles into sprint questions.
• What are your users’ pain points? start by mapping out your customer journey. It’s important to understand who your customers are.
• The Empathy Map is a visual way to better understand your users and prioritise their needs. Identify any key themes and problems affecting your users based on their quotes, actions, behaviours, pains and feelings captured throughout the user research and expert interviews.
• The Customer Journey map helps to visualise a customer’s end to end experience with your product or service.
• Swim lane diagram. Combining the Empathy map with the Customer Journey map will create a Swim Lane diagram. This diagram serves to create a heat map of the problems that exist within each step of the customer journey.
• How Might We turn this problem into an opportunity? Use the dot voting system to prioritise the How Might We notes and decide on which focus area to target for your sprint.
• Which problem do we target? Who is the most important customer, and what’s the critical moment of that customer’s experience? At the end of the day, the decider needs to select one target customer and one target event on the Customer Journey map to focus on.
• The How Might We’s (HMW) exercise helped us in defining the right opportunities, which will enable us to reach innovative solutions.

2. Ideate: Sketch out competing solutions on paper. Pumped full of inspiration and ready to ideate some solutions. This phase by coming up with ideas and building off of them to create solutions. Once you’ve got the team thinking, each participant takes time to sketch and present their ideas. During user testing, you’ll have a diverse group of people test your product and provide feedback. You need to start recruiting users that fit your target profile now

• Remix and improve with Lightning Demos: research competitors and find examples of existing products that could serve as inspiration for your solution.
• Sketch in four steps
• Notes. Start with twenty minutes to take notes of the goal, opportunities and inspiration you’ve collected earlier on.
• Ideas. Spend another twenty minutes drawing out rough ideas to form your thoughts.
• Crazy 8s. Take your strongest solution and sketch out eight different variations of it in eight minutes, known as the ‘Crazy 8s’ exercise.
• Solution sketch. Draw a detailed end to end solution for the problem in the next thirty minutes or more.

3. Decide: Make decisions and turn your ideas into a testable hypothesis. You have a lot of potential solutions for your design challenge. Now it’s time to decide which solutions you want to build.

• The process of reaching consensus on the best solution can be carried out in five steps:
• Art museum. Put all the sketches on a wall to create an art gallery. Ideally, the sketches should be anonymous, so the facilitator should assist with hanging them up.
• Heat map. Each team member is given three dot stickers to assign to the sketches or parts of the sketches that they find interesting. This is to be done in silence.
• Speed critique. Each member selects a drawing that is not their own and quickly walks through the solution, using sticky notes to capture the big ideas.
• Dot voting. Each team member is given one vote (one dot sticker) to choose the best solution and justify their decision.
• Supervote. The decider makes the final call with three votes (three-dot stickers).
• Create a storyboard: should contain scenes to provide context and familiarity to your users’ interaction with your product.

4. Prototype: Hack together a realistic prototype. You’re now ready to build the first version of your new app feature. Just something realistic enough to test with users.

• Devote the entire day to building the prototype. The secret to building a prototype is to fake it. Ideally, the quality should be good enough so that it appears real to users but not too much that you spend forever perfecting it.
• The sprint team should be split up into the following:
• Makers. Usually, at least 2 designers or engineers are responsible for creating the individual components of the prototype.
• Stitcher. Either a designer or engineer should be collecting the components from the Makers and combining them into a seamless fashion.
• Writer. Usually, the product manager should be writing realistic text to ensure that the language makes sense to the user.
• Asset Collector. They are responsible for scouring the web and image libraries to provide photos, icons or relevant content to assist the Makers.
• Interviewer. They should write the interview script for the fifth day’s customer interviews.

5. Test: Get feedback from real live users. Prepping for user testing by confirming the test schedule, finalizing interview questions, and making sure your prototype is good to go. As users test your prototype, you observe how they react and then interview them about their experiences.

• The Nielsen model suggests that you only need to interview five users who fit in with your target customer profile. The rationale behind this is that testing more than five users diminishes the value of return since you will already have identified 85% of the problems after listening to five people.
• Learning from feedback: Draw a table on a whiteboard divided up into five columns for the five customers and rows for each area or task of the prototype they addressed. (The interview should simulate a real-world environment whilst the sprint team watches the recording in a separate room.)

Design sprint phases: Understand the scope of the design challenge, ideate possible solutions, decide on the most viable solution, create a workable prototype, and finally, test that prototype with actual users.

The first rule of UX design is the user comes first

Design Sprint Main Benefits

• Save time
• Create an effective path to bring a product to market
• Prioritize the user
• Test your product before launch. Get customer reactions before making any expensive decisions.

Other Benefits of Design Sprints

• It’s all about the user. Make sure the design challenge is always focused on the user and their needs.
• Value every person in the room: From the office intern to the senior stakeholder, including people from lots of disciplines and experience levels is a key part of the process.
• Considering all angles of the problem and the solution means the best ideas will rise to the top.
• Sprints give the core team time to focus solely on a design challenge.
• Sprints lower the risk of an unsuccessful market debut. Because the team gets feedback from real users and can make critical adjustments before the product launches.
• Sprints are versatile because they can be scheduled at any point during your project.
• Sprints give the core team time to focus on problem-solving without distractions. Design sprints are all about the user and their needs. They are also versatile, and they allocate dedicated resources and time for focused collaboration. Design sprints are versatile because they can be used at any point in the project — before or after a product launch — to help improve the user experience.

A Design Sprint is a unique five-day process for validating ideas and solving big challenges through prototyping and testing ideas with customers. Sprints can help designers decide on a solution, especially when there are multiple possibilities in mind.

What you need to run a Design Sprint:

• A decider. They call the shots. They should be involved in the discussions early on since their decision will influence the sprint goal and the final product.
• Facilitator. The time keeper. They keep track of the team’s progress during the Design Sprint and ensure that everyone is playing their part. They need to remain unbiased in their opinion when it comes to decision time.
• Marketing Expert. The person who is skilled at crafting your company’s messaging to your customers.
• Customer Service. They interact with your customers on a regular basis and truly understand who your users are.
• Design Expert. They design the product and help to realise the vision of the goal.
• Tech Expert. They are in the best position to understand what your company can build and deliver.
• Financial Expert. They can explain how much the project will cost and how much the company can expect to get from it in return.

Preparation:

• Block out the entire week in your and your team’s calendar.
• No devices are allowed in the room. This is so that the entire team is focused one hundred per cent of the time.
• Stock up on post-it notes. You’ll need these to jot down ideas and map them on a wall.
• Whiteboards and plenty of markers.

Key takeaways

• The user is king. The entire design sprint process is user-centred. It builds products and services based on a solid understanding of the user’s wants and needs and asks for feedback and validation directly from them towards the end of the sprint.
• Consider all perspectives. Design Sprints gather all important people in one place. This means that there’s less of a bureaucracy and siloed structure in the organisation because the process facilitates cross-team collaboration.
• It’s efficient and effective. A sprint cuts out all inefficiencies and ineffective discussions. No more dreadful back-to-back meetings that take up your entire day leaving you with little time to get anything done. A five-day sprint forces you and your team to focus and work towards something realistic by the end of the week.
• Manage your stakeholder expectations. There is clear visibility and alignment from everyone on Day 1. Getting your stakeholders’ buy-in early on and throughout the sprint, discussions build trust and respect between all parties.
• Learn fast, fail fast. The sprint helps to obtain a clear vision of the goals upfront. It forces you to make critical decisions and solve complex problems fast. This means that you and your team can save months of design, engineering and development costs. The bonus? You’ll be able to get your product to market faster because you focussed on the right thing.

Plan design sprints:

• User research is always the first step in any sprint planning process. Your research should focus on the user problems you’re trying to solve during the sprint.
• Call in the experts: schedule short talks with colleagues or industry experts. You’ll listen to these info-packed talks during the understand phase of the sprint. Correct Scheduling short, info-packed talks with experts can help solidify the purpose of the sprint.
• Find the right space: it’s important to ensure that the space allows all employees equal opportunities to perform their job. Whiteboards to capture your ideas or hang sticky notes, acoustics so participants can hear each other easily, accommodations for anyone who needs them, and comfortable furniture that you can move around easily.
• Gather supplies: make sure everyone has what they need to participate. Some essentials include markers, sticky notes, and a lot of snacks and water.
• Establish the rules of the sprint: Figuring out the ground rules in advance sets the tone for the sprint, gets everyone on the same page and helps your team stay focused.
• Planning introductions: sprints involve cross-functional teams that may have never met before. We all know icebreakers can be a little cheesy, but they’re still a great way to help your team get comfortable with each other. Plus, choosing icebreakers that are relevant to your sprint can motivate your team and put them in the right mindset.
• Post-sprint planning: thinking about what will happen after the sprint wraps up, like how your team might use what you’ve learned to achieve other goals. You need documentation. Make sure you enlist a few people to help document the design sprint by taking pictures, collecting sticky notes, and jotting down ideas.

To prepare for a design sprint, you’ll need to conduct user research, schedule talks with experts, find the right space, gather supplies, establish ground rules, break the ice with your team, and plan out post-sprint action items.

The sprint brief is a document that you’ll share with all your attendees to help them prepare for the sprint.

• Design sprint challenge: This introduces your team to the sprint objectives
• Identify the key deliverables, meaning what your team actually wants to create by the end of the sprint.
• Logistics: where the sprint will happen and when it will be held. Who’s attending and the name of the sprint master.
• Approvers: Got some higher-ups that need to sign off on the product before launch?
• A list of resources: For short-term sprints, there’s probably a team already assigned to this project. For long-term sprints, you may need to create a plan to secure additional resources.
• Project overview: where you should explain the current state of the project, call out roadblocks that stand in your way, state early wins if you have any, and outline the estimated launch plan.
• You wrap it all up with a sprint schedule: an hour-by-hour schedule of the five-day sprint, including break times. This lets people know what to expect and gives them time to prep, so you can keep things moving along during the sprint.

Sprint master is the person who sends out the brief, but that’s not always the case. Sprint master facilitates the event, identifying the challenge and educating.

An entry-level designer’s role in a sprint:

• The understand phase, where you’ll get a clear picture of the design challenge. There will be plenty of short talks by experts that are designed to inspire you. So, make note of any thoughts you have.
• The ideate phase. The sprint master will guide the team through brainstorming activities to spark creativity and generate tons of possible solutions to the design challenge. Your main focus is coming up with ideas and putting them out there.
• The “decide” phase: Your team will decide on the solution with the greatest chance of success.
• You’ll get involved in every stage of the decision-making process.
• You also need to start planning ahead for testing, or phase 5 of the sprint.
• You might help by scheduling testers, creating survey and interview questions, and gathering necessary equipment.
• During the decide phase, the design team evaluates all potential solutions and votes for the one with the most potential.
• Phase 4 is all about creating a prototype of your product: you’ll be actively involved in creating a solid prototype for users to try out.
• You’ll ask questions, offer ideas, and review the completed prototype.
• You might also confirm the test users for phase 5.
• The test phase: where you put your prototype to the test
• you might be asked to collect user feedback by observing and interviewing users.

Feedback helps the team know what to revise before bringing the product to market.

DESIGN SPRINT is a way to quickly ideate, prototype, and validate a product idea in a week instead of waiting for months to launch a full-fledged product. The process has 5 stages — understand, sketch, decide, prototype, and validate. The sprint is a five-day process for answering critical business questions through design, prototyping and testing ideas with customers. The sprint will help you identify the most important questions to address and provide the structure you need to give you the answers.

The ideal team size in a design sprint is around 4–7 people.

A quick sprint, therefore, ensures that users get what they are looking for and not a product with unwanted features. The cross-functional team brings a wealth of different ideas on the table. The democracy approach gives everyone a chance to voice their opinions and a feeling that each vote counts. Putting users’ needs first is especially relevant in framing a better solution and solving a real human problem. Tight deadlines or time crunch sometimes helps you in coming up with the quick possible solutions. Recording everything is also crucial. You can always revisit something that got missed in between or stumble upon something completely new. Finally, with the design sprint, you are testing the viability of your idea without spending a minute into coding.

Getting started is more important than being right.

Empathy. Before you do anything else, you must spend time doing user research to understand the needs of your user and use this understanding throughout the project.

Sprint doesn’t involve users in the design process until the last day when you test your prototype. This means that many of the choices you make throughout the sprint are largely based on assumptions, hypothesis, gut feelings and thus not user research. Empathy is still at the heart of the process though. Because the team involved in the sprint is made up of people with different backgrounds and roles in the company, everyone will bring a unique perspective on the challenge. Many of the decisions you make throughout the sprint will be based on assumptions.

No amount of research, brainstorms, or meetings will ever help us come up with the perfect solution the first time. And often we need to fail to find the right way to go. The sooner we learn what doesn’t work, the sooner we can narrow in on a solution that does.

Sprints at their core are about inclusivity.

It’s always important to understand who your participants are, and make sure that this overall experience is thoughtful. When you’re designing a sprint, these participants are your users, and it’s important to understand their needs and put them first when designing a sprint.

Design Sprint Retrospectives

The retrospective is a collaborative critique of the team’s design sprint.

• Do retrospective meetings immediately following the sprint so that everyone’s thoughts are fresh.
• The goal is to make sure everyone who took part in the sprint has a chance to give feedback and think about opportunities for improvement.
• Can help you to work better as a team, improve how you communicate with clients, and even point out areas where you can grow as an individual.
• Where people actually felt comfortable contributing, and we focused on continuous improvement.
• Retrospectives are about empowering, not shaming.

Key questions in a retrospective

1. What went well?

• Analyze your team’s wins, and think about how they could be applied to future sprints.
• Questions you might ask during this part of the retrospective include
• Which tools saved you the most time and effort?
• When did you feel the most satisfaction?
• What helped you make your best contribution to the team during this sprint?
• This is also a good time to acknowledge a team member’s strong performance. Celebrating successes builds relationships and increases cohesion and harmony within the team!

2. What can be improved?

Know what went wrong, so that you all can do better next time.

Questions you might ask during this part of the retrospective include:

• What went wrong that caught you off guard?
• Which problems came up the most often?
• When do you think we experienced the biggest challenge as a team?

Then, examine the sprint’s outcome or final product, and ask questions like:

• Did the team overestimate or underestimate the work required to complete the design?
• Did an external factor derail your productivity?
• And most importantly, does the final design actually solve the user problem?

Identify ways that the team could have ended up with a better solution.

Lessons learned

Take lessons learned into your next design sprint. Before your next sprint, review the conclusions you reached at the end of the last retrospective. Your conclusions should inform how you conduct the next sprint.

Questions you might ask include:

• What did you discover during the sprint that you’re still wondering about?
• How could the current process be holding the team back from creating better solutions?

The person who led the sprint will guide the conversation, and someone will take notes so that the team can use the feedback to make the next sprint even more productive.

During a design sprint, the focus is on:

1. Understanding the design challenge
2. Ideating solutions
3. Deciding which solutions to build
4. Prototyping a few solutions
5. Testing those prototypes

Consider each phase of the design sprint to structure the feedback: understand, ideate, decide, prototype, and test. At what point were there missteps? What caused those challenges?

Groupthink can occur in a group discussion when one person shares an opinion and everyone immediately agrees with the opinion, instead of sharing their own feelings about a topic. Groupthink prevents each person from having an equal say, and it might mean certain areas for improvement are overlooked.

Speak up and share your suggestions for how the next design sprint could be better. Don’t be afraid to suggest anything you think will improve the project or next sprint. The only bad suggestion is the one not shared!

Retrospectives are collaborative critiques of a design sprint that allow input from all participants.