How I plan and execute my version of "Design Sprints"


The "Design Sprint", as popularised by Jake Knapp for Google Ventures, is a five-day process for answering critical business questions through generating, prototyping, and testing ideas in order to learn about users. Participants work together to compress months of design and development time into a single week, testing ideas with real users before making any expensive commitments.

"Design Sprints" generate a lot of interest and excitement – generate, prototype and test ideas to learn something new… in five-days! What’s not to like!? However, I find them impractical to run the original format with teams and stakeholders – here's why...

Problems I find with "Design Sprints"

1. They demand too much time and resources

The biggest problem I’ve experienced (so far), is getting people to commit to a succession of days without interruptions. I’ve also found it hard justifying the amount of time with people who are managing budgets, even when demonstrating past successes and potential cost savings.

2. I’ve not experienced a demand for a five-day turnaround

I’ve personally never experienced demand for a conceptualised, prototyped and tested idea turned around within a five-day timeframe within the public or private sector.

3. Too many people feel self-conscious or intimidated by the sketching session

I find that some people (especially participants who are less creative or more introverted) really struggle with the sketching aspect of idea generation, even with the instruction that they can simply write out ideas. I often notice them stalling, looking around at others furiously churning out sketches around them and then becoming self-conscious or intimidated.

4. Other work commitments don’t stop

Even with the strict direction to not look at devices during the "Design Sprint", people tend to struggle to comply, especially for an entire day. There is always other work and life to distract them – and that’s fine by me.

How I plan my version of "Design Sprints"

1. Participants tend to know the subject

The core premise of Jake Knapp’s "Design Sprint" is that a team without prior subject knowledge can utilise existing knowledge from stakeholders in order to rapidly develop and test ideas to learn about users. This has not been the case in the situations that I’ve run "Design Sprints".

2. Condensed – less time demanding of participants

To respect people’s time, I try to condense the "Design Sprint" as much as possible, without compromising on output. I find that this makes people more present during the sessions, and less susceptible to distractions as a result. So far, I have found that I only need two days for a "Design Sprint".

3. Flexible – fit in with participants day

I plan for as much flexibility as possible, allowing participants to fit activities in with other work commitments and day-to-day life. By doing this, I’ve experienced less drop-outs and late arrivals.

I do this by letting participants complete activities independently in their own time – especially when it comes to sketching ideas, which is less intimidating when completed in private, and provides less constraints as it gives people more casual thinking time (for example, on a lunchtime walk). I’ve occasionally had problems where participants have not completed the activities ahead of time, however I try to mitigate this with timely reminders.

Worth noting, I’ve also found that days don’t have to be consecutive – giving a day between makes it easier for participants to plan their time and adequately complete activities, with the added benefit of more casual thinking time.

4. Highlight critical decision points

Some people will always be too busy to fully participate. As advocated by Jake Knapp, I find it really useful to highlight key decision points – such as prioritising problems and voting on ideas – for important stakeholders who might find it hard to commit time. I’m also willing to move these timeslots in order to allow as many people to attend as possible. I start these decision points by bringing people up-to-speed with anything they have missed.

Workshop image between the core team and partnered stakeholders

Workshop between the core team and partnered stakeholders

My condensed "Design Sprint"

I break my sprints down into two key activities:

  • Establish context and problems

  • Inspire, generate and select ideas

I tend to run these sessions over two days – however there is no reason why additional days could be added in-between days to allow more time for participants to complete independent activities.

Establish context and problems

During the first day I focus on setting the context for the next day. This will include listing the users, and mapping their journeys – starting on the end point and start point, then filling the steps in-between, highlighting key problems throughout the journey. I find that most participants tend to know the journey pretty well, and help each other fill in the gaps and discuss the problems throughout.

Once we have mapped the high-level journey, we then reframe the problems as "How Might We" challenges. These "How Might We" challenges will be prioritised by participants, promoting clear, agreed focus for the next day.

I then set my first independent activity – "Lightning Demos" – in which participants are tasked with collecting good examples that solve similar challenges, encouraging them to look to other industries as much as possible. To make this easier, I provide offline and online templates for participants – including space to sketch or add a screenshot, and a section to summarise the concept, why it is good, and how we can use it.

Lightning demo example screenshot showing Babylon Health profile page

"Lightning demo" example of a Babylon Health profile page

Inspire, generate and select ideas

Day two starts with "Lightning Demos" – in which participants share their examples with each other – the goal being to provide each other with inspiration when generating ideas. This activity is extremely important for generating solutions as it really does inspire other participants, while also being very approachable for participants who are less confident in sharing their own ideas.

I then set my second independent activity – brainstorming ideas – in which participants privately generate their own ideas, writing or sketching them, using the examples shared during the "Lighting Demos" as inspiration.

Participants then regroup to share their ideas in the form of a "Speed Critique". Depending on the dynamics of the group, I will either run through the ideas (as recommended by Jake Knapp) or let participants share their own ideas. As we talk through the ideas I will write down key themes of the ideas.

Example of a sketch shared by a participant during a Speed Critique

Example of a sketch shared by a participant during a "Speed Critique"

I will then cluster the ideas into themes where possible, ready for participants to vote on their favourite themes (as opposed to the sketched ideas) to take forward.

Image example showing a theme of ideas generated during a workshop

Example of a theme of ideas generated during a workshop

Enough to progress

For me, that’s all I need from a "Design Sprint". The real benefit comes from the alignment promoted across the team and stakeholder participants, with agreed ideas to take forward to learn something new. These ideas can then be prototyped in their own time – be it simple low-fidelity sketches, or high-fidelity working prototypes. These prototypes are then ready for testing in order for the team and stakeholders to learn from real users in a quick and relatively cost-effective way. Just maybe not as quick as five days…

Read more of my thoughts

Fancy a chin wag?

Whether you are just looking to discuss opportunities, looking for help starting out, or want more information - get in touch and I’ll be sure to get back to you

Get in touch at