Running a design sprint

What is this recipe?

A Design Sprint is a highly structured, five-day process for solving big challenges and testing new ideas with real users. Think of it as a way to fast-forward into the future to see how your idea works before you commit time, budget, and resources to building it.

It brings together a small, cross-functional team from different parts of the council (for example, customer services, IT, policy, and a service lead) to work intensely on a single, important problem. The week starts with a problem and ends with a realistic prototype that has been tested with actual residents.

The sprint’s core strength is its focus on action over endless discussion. It forces decisions, creates a tangible output, and replaces guesswork with real user evidence. It is an excellent way to reduce the risk of building the wrong thing, saving public money and delivering better services for residents.

When is it good to use?

This recipe is best used when you are at the beginning of a project or when you are stuck on a particularly complex problem. It is not for small, simple fixes.

When you need to kickstart a major new project, like redesigning the council’s Blue Badge application service.
When different departments have conflicting ideas about how to solve a problem, such as improving the process for reporting missed bin collections.
When a project has lost momentum and needs a fresh approach and clear direction.
When you have a high-risk, high-cost idea and you want to test your assumptions before committing a large budget.
When you need to quickly understand how residents will react to a proposed new digital service.

How does it work?

A Design Sprint follows a structured, step-by-step process over five days, with each day having a specific goal.

Day 1: Map the Problem. The team comes together to agree on a long-term goal. You will listen to ‘lightning talks’ from experts across the council to build shared knowledge. By the end of the day, you will have mapped out the customer journey and chosen a single, specific target for the sprint to focus on.
Day 2: Sketch Solutions. Instead of group brainstorming, each team member will individually sketch their own detailed solutions to the target problem. This allows for a wide range of ideas, not just the loudest voice in the room. This isn’t about artistic skill; it’s about getting ideas down on paper.
Day 3: Decide. The team critiques each sketched solution and decides which one has the best chance of meeting the sprint’s goal. This is done through a structured voting process, with the senior stakeholder (the ‘Decider’) making the final call. This avoids endless debate and creates a clear path forward.
Day 4: Build a Prototype. You will create a realistic-looking but fake version of your chosen solution. This prototype is not working code; it’s a façade designed to look real enough to test with users. This can be built quickly using tools like Figma, PowerPoint, or even paper. The aim is “maximum realism, minimum effort”.
Day 5: Test with Residents. You will show the prototype to five real residents in one-on-one interviews. You will watch them use it and listen to their feedback. This is the moment of truth where you learn what works and what doesn’t. At the end of the day, you will have clear, evidence-based next steps.

An example

A County Council wants to improve the process for applying for a school place. The current online system is clunky, leading to a high volume of calls to the support centre from confused parents.

They run a design sprint with a team including a school admissions officer, a customer service agent, a web developer, and a content designer.

On Monday, they map the stressful journey parents go through and decide to focus on making the school selection part of the form clearer.
On Tuesday, they sketch different ways to present school information, including maps, Ofsted ratings, and travel times.
On Wednesday, they decide to prototype a map-based interface that lets parents see their nearest schools and key information at a glance.
On Thursday, they build a clickable prototype of the new application form in a design tool.
On Friday, they test it with five local parents. They discover that while parents love the map, they are really worried about how to apply for schools outside of their catchment area, a feature the team hadn’t prioritised.

The better outcome is that, in just one week, the council learned what the real user need was. Instead of spending six months and £80,000 building a service based on assumptions, they now have clear evidence to build a simpler, more effective service that will reduce failure demand and actually help parents.

What is this recipe?

When is it good to use?

How does it work?

An example

Further reading

Share this content with your networks: