Accelerated Design Sprints

Image by Freepik

Introduction

Design Sprints are a 5-day process to create and test new ideas. They can be used to explore new features for an existing product, or test a new product.

The process was developed by Google Ventures and popularised by Jake Knapp.

In this article I will:

• Describe Design Sprints
• Explain the advantages and limitations of Design Sprints
• Describe ‘Accelerated Design Sprints’ – which are a more streamlined process
• Walkthrough how to run an ‘Accelerated Design Sprint’

Design Sprints

A Design Sprint involves a cross-functional team (e.g. designers, business stakeholders, developers, BAs, user researchers). The team will spend 5 days: understanding the problem, generating ideas, converging and testing ideas with real users.

The typical format for a Design Sprint is:

The activities of each day are described below.

1. Day 1 = ‘Understand the problem’

1. Start by identifying the long-term goal (e.g. why are we doing a project, what do we want to achieve in 12 months). The Product Owner may bring a goal into the session. The team will discuss the goal (e.g. raise questions, risks and assumptions) and identify the most important Sprint questions that will be explored during the week
2. Make a map showing how customers move through the product / service
3. ‘Ask the experts’ are sessions where experts (e.g. SMEs, data analysts, user researchers) present data and insights. The team will ask questions. These insights / pain points are added to the map
4. Participants write ‘How Might We’ statements during the expert talks. HMWs are improvements framed as questions (e.g. ‘How Might We make reviewing the patient’s medical history faster’). The HMWs are affinity sorted & voted on
5. Pick a target. The decider (usually the Product Owner) picks the target area to focus on for the rest of the Design Sprint

2. Day 2 = ‘Generate ideas’

1. Lightning demos. Participants bring examples / inspiration from existing products. A team member will capture what people like about those examples
2. Sketch. Participants sketch out potential solutions. A 4-step process can be followed to produce a sketch. Step 1 = participants generate notes based on the goal, insights & lightning demos. Step 2 = participants generate lots of rough ideas. Step 3 = participants sketch 8 variations of their favourite idea (Crazy 8s). Step 4 = participants create a ‘solution sketch’ of their favourite idea – it’s usually a poster with a 3-panel storyboard, title and notes

3. Day 3 = ‘Decide’

1. Make a decision. Now there’s lots of solution sketches – a winner or winners need to be selected. A 5-step process can be followed. Step 1 = put everyone’s solution sketches on the wall. Step 2 = ask participants to silently review the sketches & dot vote their favourite ideas / part of ideas. Step 3 = the group discuss each idea (e.g. highlights, observations, objections). Step 4 = each participant votes on their favourite idea. Step 5 = the decider (usually the Product Owner) will choose 1-3 solutions they want to take forward
2. Make a storyboard. For each solution you will create a storyboard. It’s common to split into teams and ask each team to focus on 1 solution. The storyboard will provide the flow for the prototype

4. Day 4 = ‘Prototype’

1. Build a realistic façade. For each solution you need to create a prototype that can be tested with users. Prototypes can be high-fidelity or low-fidelity. Tools used can include: HTML, paper sketch, Figma or proto.io. You may be testing a new website, a feature in an app or something else!!
2. Write an interview script. Write a script which will be used during the user testing

5. Day 5 = ‘Test’

1. Test with users. Each prototype will be tested with approximately 5 users. The team will live stream these interviews & make notes about what went well & not so well. Notes should be based on what users did and said
2. Affinity sort the notes. Notes are put underneath the storyboard. The team will discuss and identify patterns in the feedback. The team will look at the Sprint questions and see which ones were answered
3. Wrap-up. Agree on next steps. It could be that another prototype is required to incorporate the user feedback. Or you have enough information to develop the idea and release it to real users

Advantages & limitations of Design Sprints

There are many advantages to running a 5-day Design Sprint. They can:

• Bring together a wide range of stakeholders to share knowledge & develop a common understanding of the problem

• Encourage people from different roles to generate lots of ideas

• Test ideas with real users, so there is greater confidence they solve the problem

However, a common problem with Design Sprints is getting 5-days with an entire team. It’s difficult to get 5 days with all the stakeholders / SMEs / development team. Additionally, 5 days can feel like a long time for small or medium sized goals.

This has led some teams to compress the Design Sprint into a 1 day ‘Accelerated Design Sprint’ (ADS). Accelerated Design Sprints are particularly useful for exploring features & improvements to existing products.

Accelerated Design Sprint

An Accelerated Design Sprint takes the best aspects of Design Sprints and compresses them into 1 day.

A cross-functional team broadly follow this format:

• MORNING = understand the opportunity area (diverge). This involves presentations and exercises to understand existing user behaviour, pain points & competitors

• AFTERNOON = generate & refine ideas (converge). This involves sketching, voting of ideas & testing those ideas

It offers the following advantages:

• Compressed timeframe means it’s easier to organise with SMEs / key stakeholders

• A shorter timeframe is sufficient if a product already exists & the team want to explore new features / improvements

• Energy levels among participants are higher as its more focussed in a single day

Preparing for an Accelerated Design Sprint

To setup a successful Accelerated Design Sprint requires preparation.

A) Participants

Invite a cross-functional team. These are people who have knowledge of the problem / opportunity space, or will be involved in creating the solution. Typically, this includes:

• Product Owner
• BA
• Designer
• User Researcher
• Developer
• Business SME / stakeholders

You may also want to invite: QA, Delivery Manager, Data Analyst & anyone else who has knowledge/insights or can generate new ideas. 7 – 10 people is a good team size.

B) Pick a facilitator

The facilitator will setup the session & facilitate the group. They will also set homework (e.g. asking participants to bring examples from other products).

The facilitator could be: a BA, a designer, or anyone else in the team. It’s useful if the facilitator has experience of Design Sprints.

C) Format

Design Sprints can be run in person or online - using tools such as Miro. The activities can vary depending on the facilitator – however an example format is provided below.

Running an Accelerated Design Sprint (MORNING)

The morning sessions are about understanding the context / problem area.

Introduce Design Sprints / expectations (15 mins) – start by explaining the context / purpose of a Design Sprint. It’s important to stress that people should have open minds. Reiterate the aim of the Design Sprint is to increase understanding and generate ideas that will be tested with real users. Reinforce that it’s an interactive session.

Introductions (15 mins- optional) – allow each person to introduce themselves and their role.

Ice breaker (20 mins - optional) – run an ice breaker to get people into a creative mindset and help the team gel. Example activities can include: 2 facts 1 lie, draw an imaginary animal etc.

Introduce the goal & discuss (30 mins) – PO or BA will present the goal of the Design Sprint & why it’s a goal they want to solve. This could include: the hypothesis behind the goal, how it aligns with business goals, why it’s worth solving and any important context. A goal could be: “Allow kids to create an online, gamer identity they’re proud of + want to share with others”.

The team will discuss the goal, including a) questions they have about the goal, b) whether they agree / have any concerns, c) what needs to be true for us to achieve the goal, d) what questions they have that they’d like to answer today.

Sessions to understand the problem / context (1.5 hours): a number of sessions to understand user journeys, pain points and the user context. These can be presentations or activities.

Example presentations include:

• User researcher = present what is known about the users, the context in which they use the product, how they’re currently solving the problem, pain points
• Data analyst = present the online user journeys, drop-offs, key insights from the data
• SME / business stakeholder = present the business context, any constraints/opportunities, known issues, upcoming developments

During these presentations I ask team members to write notes:

a) yellow post-its = interesting / key points (e.g. what users say / do / want, interesting facts)

b) another colour post-its = problem statements to explore in the afternoon (written as How Might We’s). How Might We’s are more specific than the Sprint goal – examples include: “How Might We make games more social”, “How Might We increase kudos in our games” etc

Example activities include:

• User journey mapping = based on the presentations draw out the main user journeys and identify the pain points
• Customer profile map = identify the jobs to solve for key users, gains & pain points. A) Customer job = things they want to do / accomplish by using our product e.g. compete against a friend, B) Gains = benefits they get from doing those jobs e.g. social kudos, C) Pains = what gets in the way when doing the job e.g. don’t know when friends are free to play a game. I often get the team to pick the top 2 jobs / gains / pains – and discuss whether they think we meet them. This can be a great way to get the team thinking from a customer perspective. Here’s an example format:

• Competitor demos = participants bring examples from other products who have solved this problem, or have something we could use in this problem space. These could be direct competitors or something more left field

Running an Accelerated Design Sprint (AFTERNOON)

The afternoon is where the team generates ideas & agree which ideas to take forward.

Agree on 1 – 3 problems to solve (45 mins) = affinity sort the HMWs from the group. Dot vote and pick 1 – 3 HMWs to take forward.

Generate ideas (1 hour) – I typically use crazy 8s. Participants have 10 minutes to generate 8 ideas. These are presented back to the group. We use dot voting to identify the most popular ideas. You can also use ‘invest in an idea’ and give people a virtual currency to assign value.

Refine an idea (1 hour) – each participant will pick 1 of the most popular ideas. They can add other ideas into it. Each participant will generate a ‘refined idea’ – adding a title, more sketches / storyboard & a description. Ideas are presented to the team. Feedback can be collected using a rose format. Ideas are voted on and 1 - 3 winners are taken forward.

Test it (1 hour - optional) – in an ideal world you would test the ideas with users. However, because your ideas are likely to be paper sketches it can be difficult to get user feedback. To solve this, we asked UX to take the ideas forward and spend several days developing clickable prototypes that are tested with real users. The user feedback is presented to the team 1 week later.

Here's the agenda for an Accelerated Design Sprint I ran:

Tips for running an Accelerated Design Sprint

1. Introduce the day correctly – there will be people who have never in an Accelerated Design Sprint. Or who aren’t usually asked to sketch ideas. Make sure you set the scene, state the output of the ADS & encourage people to participate
2. Have plenty of breaks – it can be tiring for participants absorb lots of information & generate ideas. Plan lots of breaks & keep energy levels high
3. Be flexible about the format – select activities & sessions that suit your need. If you have lots of user research – allocate time to that in the morning. If you don’t have lots of research then create a customer profile map. If it’s a well understood problem area: you could run an activity about how to measure success of the new idea (e.g. what metrics are key & how long to run it for), what the challenges could be (e.g. cost, personal data) & what the next steps are for an idea (e.g. tech spike, UX mockup)
4. Be clear about the output – will it be a single idea that is user tested in the afternoon? Or three ideas for UX to prototype & then user test?
5. Running remotely – if you’re running it remotely - the following tools can be useful: a) Slack for comments & sharing images, b) Zoom for presenting the session, c) Miro / Figma /Mural for adding idea & insights
6. Goals can be big or small – the format is adaptable. You could bring a big goal (e.g. ‘Create sticky features that keep kids on our site’) or a small goal (e.g. ‘Design a multiplayer experiment in an existing game’)
7. Playback the findings to a small group – I find it useful to write-up the session & playback the findings to the PO & Tech Lead. Then circulate the write-up to the wider group. The write-up includes: attendees, goal, pre-requisites, presentations, HMWs, Crazy 8s and winning ideas

Conclusion

Hopefully you can see how Accelerated Design Sprints can be used in a discovery phase to explore new ideas in 1 day!!

The output can be significant. It includes:

1. Common understanding of the problem / opportunity
2. Lots of useful questions & ideas
3. Designs that are - or will be - user tested
4. Everyone has input which generates buy-in from the team

They’re particularly useful when adding new features into existing products or iterating features.

Thanks: I’d like to thank Graham Densham (BBC) and Jess McKenna (Push Dr).

Useful links

https://www.gv.com/sprint/

https://uxplanet.org/whats-a-design-sprint-and-why-is-it-important-f7b826651e09

https://medium.com/push-doctor-design/how-and-why-we-accelerated-our-design-sprints-82aedaf75615

https://designnotes.blog.gov.uk/2023/01/09/how-we-ran-a-1-day-design-sprint-to-help-users-understand-visa-options/

Author: Ryan Hewitt, Senior Business Analyst

Ryan Thomas Hewitt has over 5 years business analyst experience working for blue chip companies in India, Germany, USA, Italy and UK. Ryan holds certifications in scrum, lean, ITIL, change management and NLP.