In an ever-changing, fast-paced world of product development, we often need to design solutions speedily. There’s rarely time for fully-fledged, robust research and a discovery process that takes weeks to create tangible results.
Luckily, there are many frameworks and techniques that can help us achieve this goal while maintaining the final quality of the solutions we deliver.
Let’s explore one of the most well-known approaches for a speedy design process — a design sprint.
The biggest challenge with a proper design process is that it’s time-consuming. It takes time to truly understand the problem and our users. Figuring solutions that can address user and business problems is also time-consuming. Not to mention our potential solutions tend to be ridden with assumptions, which also, you guessed, take time to validate.
But we rarely have the privilege of having a lot of time. Consequently, the design phase is often rushed, and when it’s rushed, it’s easy to start skipping steps along the way, jumping straight into Figma and preparing UIs based on a gut feeling and so-called expertise.
The result of this approach is often solutions that look pretty but are unlikely to truly nail the problems they were designed to solve.
Design sprint strives to address common problems with the design process.
The objective here is to go through all stages of the design thinking process, without skipping any steps, within a focused timebox.
This focused, short timebox is what differentiates the design sprint from the normal discovery process.
By engaging all critical stakeholders and focusing fully on solving a particular problem, we can often achieve more within a week than we would do with a month of “business as usual” approach.
There is more than one way to approach the design sprint. Let me share the three most common ones I encountered in my career.
The term “design sprint” was coined and popularized by Jake Knapp in the book Sprint.
In his book, Knapp describes how Google Ventures approaches helping startups create and validate solutions quickly. This variation of a design sprint lasts for one week with a clear objective for each day.
The very first day fully focuses on understanding the problem from a user and business perspective. It’s also the most important day of the whole sprint.
We often jump straight into ideation or solution design after briefly hearing what problem we are solving. But without truly understanding the root cause of the problem and all possible dependencies, we’ll most likely miss some critical pieces of the puzzle.
Some exercises used during this day include:
The primary outcome of this day is a well-defined, detailed problem statement that’ll guide the group through the following days.
Once you have a solid understanding of the problem you are solving, it’s time to ideate potential solutions. Combine the inspiration phase, individual work, and group brainstorming for the best results.
Start by giving participants some time to do benchmarking and find exciting solutions that already exist out there. Then, let people share them with others with a commentary on why they believe it is a good direction. It will give everyone in the room a healthy dose of inspiration.
After this, proceed to individual work. Give the group space to explore and ideate solutions, ideally already sketching how they could work in an existing user flow.
Share these individually-brainstormed ideas with the whole group to get further inspiration from each other and build on top of their ideas. Repeat the cycle two or three times until your ideas are refined.
On day three, you decide which idea(s) you believe the most in. Depending on the number of ideas generated on day two, ask each participant to choose one or a few of their ideas. Gather them all in one place.
Walk by each idea one by one and accommodate some time to discuss them in detail. Where do they excel? Where are possible risks? What are the most important assumptions?
After the review, discuss with the group the most important criteria you should include when choosing the most promising solutions. You can make the final selection by discussion, dot-voting, or even simply having the most suitable person to choose the idea(s) to pursue on behalf of the whole group.
Depending on the group size and resources you have allocated, you can decide to explore one particular idea or choose a few you want to test.
Now it’s time to prepare testable prototypes of your chosen ideas. Depending on the type of solutions you’ve chosen, these might range from:
Since you have limited time, focus on your most important assumptions for each solution you have. The main goal of the design sprint is to learn and validate solutions, so design your prototypes in a way that maximizes the chances of a breakthrough — don’t play it safe.
You wrap up the design sprint by testing your prototypes with users. Five tests per idea seem like the most optimal number. It’s a small enough number to accommodate within one day while being a significant enough sample to discover most insights and opportunities. Note down all learnings and insights you capture during the tests.
After the whole design sprint, there are three choices you can make depending on the test outcome.
In some cases, a week is short. In other cases, it might be a really long time. If you want to run design sprints regularly, it might be hard to accommodate a whole week every month or so. So in practice, I’ve often encountered shorter variations, three days being the most common one.
The whole process doesn’t differ from a classic design sprint, although we pack the whole process into three days.
For example, you could spend:
Although shortening the process inevitably makes you cut corners, sometimes being done is better than being perfect.
One of the most extreme approaches to design sprints is to timebox the whole process within one day. Containing all steps of the design thinking process in one day might seem impossible. And yes, it is probably too short for ambiguous and complex challenges.
But not every problem requires the whole discovery process and working from scratch. You might work on an issue that’s already very well-defined or even already have some potential solutions on the table.
And even if you don’t, not every problem is big enough to require a few days of work. If you are working on a minor issue (for example, trying to figure out why your registration wall is not converting), one day might be enough to tackle it.
The one-day sprint might still make sense even for those complex problems, though. Sometimes it might be better to run five one-day long design sprints and iterate on the go than to have one fully-fledged design sprint without having time for any next steps and pivots.
To give you context, this is how a sample agenda for a one-day design sprint could look:
This agenda is just an example, and the actual agenda will depend on what you already have. For instance, if the problem is already well-defined, you can spend just fifteen minutes to recap it briefly. To make a one-day design sprint a reality, we often resort to unmoderated, asynchronous tests with users — this is why I accommodated only forty-five minutes for that.
Ultimately, the goal of the design sprint is to go through all stages of design thinking speedily, and there are many ways to achieve it.
If your team is overwhelmed with fires on a day-to-day basis, it might make sense to accommodate four hours each day for the design sprint activity instead of whole days.
You could even split the sprint into two parts, with a few days in between to tackle other issues.
It’s all about the tradeoff. The classic sprint is the base – five days of fully focused work on solving a particular challenge. Shortening the time or introducing distractions will decrease the resulting quality.
Sometimes it’s the only way, though. It’s critical to balance the perfect design process with the constraints we have.
Let me wrap up by sharing some tips from my personal design sprint experiences.
One of the main benefits of a design sprint is the time pressure it creates. After all, work expands to the time allocated for its completion.
The process is supposed to feel rushed. It forces people to truly focus and motivates them to work the hardest. Once again, done is better than perfect at the end of the day.
You don’t want to spend half of your design sprint on the neverending discussion about which criteria are more important or which idea should make it to the final prototype.
Don’t get me wrong, group conversations are invaluable and help people to get on top of other ideas and discover new insights. But if it takes too long, the decision must be made. For each step of the design process, decide on the person most suited to make the final call and respect that.
With all the rush to finish the whole design thinking process in a short time box, it might be tempting to have short or no breaks at all, but it will actually slow you down.
The break helps people recharge batteries to focus on the exercises and the next steps. People also tend to multitask less when they know they’ll be able to catch up on their topics during breaks.
Plus, there’s a reason for the saying that the best ideas happen in the shower. Sometimes the best solutions pop up when people don’t actively think about them.
The goal of the design sprint is to go through the whole design thinking process within a limited time box. It strives to achieve speedy results without skipping any steps required for proper problem solving.
Although the classic design sprint is a five-day long process, you can try out many variations. For smaller problems, you can even accommodate the whole cycle in one day.
The uses can vary from an occasional design sprint for kickstarting new initiatives, or even periodic sprints, such as:
These options make design sprints a regular part of the design process. I never managed to build an approach based solely on these sprints, though.
While design sprint is not a silver bullet or a perfect approach, I strongly encourage you to experiment with them and determine if they can have a role in your context. Although I heard a few times that people tried it out and didn’t like this approach, I’ve yet to hear someone say a design sprint was a waste of time in general.
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
