On your marks, get set, go: Our guide to UX/UI product sprints

A product sprint is a fast-moving collaborative design process that runs over two weeks. It aims to rapidly explore, learn and solve a single or a set of problems. It’s value lies in speed and condensing a longer traditional human-centred design project into two weeks, to create solutions in a relatively inexpensive way. In this article we’ll explain the benefits of sprinting and help you decide if a product sprint is the right framework for your next project. We’ll then share our tips on how to set up your sprint to be a success.

Move fast - In a product sprint, we consolidate weeks or months of design into a highly focused two-week project to get your project off the ground faster.

Kill ideas quickly - The benefit of having a surplus of ideas is that we can get rid of some to focus on the ones that have been proven by customers to be desirable. You can stop wasting time on things your customer doesn’t really want so you can develop the ones they do.

Spend time designing, not documenting - During the sprint the team communicates daily, shares thinking and builds on ideas to quickly design customer approved solutions. This close and collaborative way of working, means we spend less time documenting design specifications and preparing for big sign off moments. This gives us more time on bringing proven ideas to life.

Sounds great? It is. But before jumping into a product sprint there are a few things to consider. Firstly, is the Product Sprint the right project framework for the problem you want to solve?

The appeal of fast and cheaper processes can be alluring, but it’s not the go-to framework for every design problem. We’ve put together some questions to help you decide if a Product Sprint is the right way to go.

Do you and the team know the audience and the problem well?

In a product sprint, we assume a Discovery and Understanding phase of the project has been completed where you have spoken to your customers to understand their wants and needs and dig deeper into the root of the problem. If you’re not confident you know your audience well and you’re still learning about the problem, a product sprint might not be the best first step.

We suggest doing some research first to get more clarity about the problem and the people you’re designing for, before starting a product sprint. As we (and American inventor Charles F. Kettering) like to say, a ‘problem well stated and understood is a problem half solved’.

Are you trying to tackle multiple complex or unrelated problems?

In a product sprint, we move fast to find the most innovative and valuable solutions to your problems. Trying to tackle a lot of problems in a product sprint spreads the focus too thin. If you have several big complex problems to solve, prioritise the most important issues, then do a few targeted product sprints or consider doing a longer design project. Focus and constraint drive innovation. Remember we’re aiming for a Tesla, not The Homer.

Are you trying to design a complete, fully articulated product to be sent off for development?

Testing the desirability of a solution with your customers is the ultimate goal of a product sprint. The focus is on taking an idea, creating a design and getting feedback early to come up with a working solution. Expanding the goal to also include detailed, development-ready designs is undesirable and counterproductive because it takes the focus from customer problems to feasibility and detailed documentation.

So what do you think? Does it sound like a product sprint could work for you? If you know your customers well, have a contained set of well-researched problems and you want to test the desirability of your ideas then a Product Sprint could be a great way to get cracking. Let’s take a look at how to set up for success before starting a product sprint.

The preparation before a sprint is just as important as the sprint itself. Here are our tips to help you get the most out of your next product sprint.

• Expect to move fast. This might sound obvious but sometimes this can be the hardest part. Speed means that you don’t get to take in all the detail of the scenery along the way, but you get to the destination faster. With product sprints, decisions are fast and not all avenues, features, steps and screens can be explored and completely designed.

• Write a contained sprint definition. This establishes the direction everyone is moving towards and describes what success looks like. This could be something like, “…by the end of this sprint we will have a validated solution to X problem so that Y can…”.

• Include a diverse range of people, skills, knowledge and expertise so you can create solutions that are well informed. Don’t try to include everyone in the sprint. Keep it small to less than 8 people.

• Schedule daily check-ins to share progress, clear any blockers or ask questions.

• Cut out as many external distractions as possible. During a sprint, momentum matters. Try to keep two weeks clear for the team, so they can dive deep into the process.

• Where possible, remove presentations and approval milestones from within the sprint timeline. This enables you to move faster and without distractions so that you can present your designs clearly at the completion of your Product Sprint.

Product sprints are a fast, fun and relatively inexpensive way to solve problems, but they aren’t the cure-all solution for every problem. Before you dive in, spend the time to make sure it’s the right framework for you and invest the time in preparation.