If you’re in the process of creating a website or application, and run into a problem, it’s important to stop and take a step back. As well as looking beautiful and functioning effectively, a product should also provide users with an experience perfectly suited to their needs. By failing to understand your users and their expectations, you can end up wasting both your internal resources and your clients’ money. That’s why we use product design sprints to test a client’s idea or answer their critical business questions. It’s now a choice tool in our repertoire when working with a new client. It helps us to set a direction, anticipate and avoid problems, and reduce wasted time, money, and effort.

Why we use design sprints

Pioneered by Google Ventures, product design sprints are a process we started using early in 2015. They’ve been highly successful at refining the work we do for our clients, invaluable for new businesses, websites, and products. They enable us to validate new products and avoid potentially costly problems down the line. [pullquote]In one week, we come to understand what the problem is, come up with solutions, and create a prototype to validate them[/pullquote] In one week, we come to understand what the problem is, come up with solutions, and create a prototype to validate them. Through this process, we are able to achieve a number of core goals, including:

• Greater clarity: we know how the product is going to look and feel, as well as the purpose it should serve.
• Risk reduction: we validate concepts and assumptions with real users in order to avoid costly mistakes in the future.
• Saving time: design sprints are quick and effective way to identify problems without going through the full development and release process.

The week is intense and insightful; and we quickly identify what works and what doesn’t. From there, we can make the right recommendations to get the client’s product on the right track. So, how do you hold a design sprint for your next project?

How we prepare for the sprint

Design sprints are run in one-week cycles. From our experience, we believe a single sprint can validate most user experience problems. With only 5 working days, we need to make sure every hour counts. You’ll need to gather the right stakeholders, and, for the duration, there should be 100% commitment. When we run a product design sprint, we always include a designer, a developer and, most importantly, a facilitator to lead the process. From the client, we would aim to include a product owner (the person able to make decisions) and ideally stakeholders representing key areas such as Customer Service, Marketing, IT, and Finance. Who attends is entirely dependent on your business, but the key decision maker must be included and all attendees must be present for the entire sprint. Finally, we need a big room with lots of whiteboards and space for brainstorming, paper, post-it notes to be stuck up everywhere. This can be either here at our offices, or at our customer’s location.

Getting to work

Each day we focus on a new aspect in order to meet the end goal:

• Day 1: understand the problem.
• Day 2: come up with ideas.
• Day 3: decide which ideas to progress.
• Day 4: create a prototype.
• Day 5: validate with real users.

Day 1

Day one focuses on understanding the main goal of the project or problem we are trying to solve, and identifying who the users are and what they want from the product. We throw around any ideas, analyse existing products and look at what competitors are doing. We then look at the primary user journey and decide what areas are going to be focused on for the rest of the week.

Day 2

Day two is all about individuals coming up with ideas of their own. At this stage, there are no bad ideas! We use processes such as note taking, mind maps, crazy 8s, and storyboarding. Nothing is too small to be explored: we once came up with 160 different ways of carrying out search.

Day 3

Day three is all about pulling together everything identified on days one and two, and making decisions. We analyse the merits and critique the flaws of each idea. Following this, we use dot voting to allow individuals to pinpoint individual features they like from each suggestion. We make a list of all the assumptions that we want to test on day five with the prototype and, as a group, decide on the exact elements we want to test in the prototype on day five. We then draw these up on the board as wireframes.

Day 4

Day four focuses on two things. Firstly, the prototypes that the designer builds, which are based on the wireframes established on day three. This ensures that everyone in the room is sure about the exact functionality that will be expected in the prototype when it is tested on day five. Secondly, as a group we decide on the test script. This contains the guidance, questions, and tasks read out to users, which all hone in on the assumptions we want to validate on day 5. A couple of important things to remember: It’s not meant to look pretty, it’s not meant to be perfect, and it’s not meant to be hung up on branding. We maximise the usefulness of our time by focusing on the parts which are critical for a user to review and which give us those important insights.

Day 5

Day five is all about bringing in real users. During the planning stages, we carry out research to identify a group of users who can put your designs and mock product to the test. We recruit users in a number of different ways; but it is important that we get the right users to test the concept. This often includes identifying potentials and qualifying them ourselves, sending out a survey on social media, and in some cases, employing a professional service that can help to find the right sample users. To get the best variety in results, we tend to aim for at least half a dozen users to carry out the testing. [pullquote]monitoring exactly what the users does, rather than what they say, is the most important aspect of user testing[/pullquote] At Degree 53, we have testing facilities set up allowing us to record what is happening on the device, how users are interacting with the prototype, and the user themselves. In another room, the stakeholders watch this as it happens. The facilitator is the only person present with the user. The facilitator will take them through the test script paying close attention to the user’s actions. From our experience, the majority of people will say that they like the product. This is why monitoring exactly what the users does, rather than what they say, is the most important aspect of user testing. This is by far the most exciting part of the design sprint, as it helps stakeholders decide whether they want to bring the product to life, refine or change the concept, or scrap the idea completely. (That’s probably not as exciting, but at least they haven’t gone through developing a product without seeing results.)

Analysing the aftermath

Whatever the outcome of the design sprint, stakeholders will ultimately have a much clearer idea of how they can solve a digital problem or if their new business idea is heading in the right direction. Within just five days, we are able to create a working prototype, with real user feedback and any criticisms and constructive feedback can be used to make a decision. So why do we love design sprints? In just five days, we can achieve an outcome which could normally take months. It condenses everything down to the basics, and gives us an understanding of exactly what we need to do. Try one for yourself.