Skip to main content

Problem solving with a design sprint

Posted by: , Posted on: - Categories: Agile, Design

While my team was going through a quiet period on current projects, I decided to run a week-long ‘design sprint’ with a smaller sub team to begin to tackle our next project.

Our service is focussed on building systems that get data from other systems, so it can be easy to approach all of our projects in the same way. But - we must remember that there are humans using these systems - we don't want to spend time and money developing something to find out it's not what was needed in the first place.

The aim with the design sprint was to help us understand the problem we were trying to solve, generate ideas and get a good indication whether we were on the right track. And,  if we weren’t, we’d only spend a week finding that out, rather than months. It was win-win.

We set up a structured format and we hoped the time constraint would force decisions and quick progress. We planned to prototype a solution to test our assumptions with real users.

Image of the design sprint in progress - team members at a wall with post its
The design sprint in progress

The set up

We block-booked a room that would become our war room for the week and rallied our troops.

Our team was made up of a product owner (designated decision maker), user researcher, business analyst, front-end developer and interaction designer (also facilitator - me).

We invited a couple of experts that work with the existing processes along to join us and help answer questions.


We discussed the problem, setting a long-term goal and noting our biggest assumptions and questions down. We also mapped out the current journey and saw where existing issues were.

While this was an important day, it was also a slow day that involved covering a lot of old ground. I wasn’t sure that everyone saw the value of the process quite yet. However, we were ready to start solving our target problem in the morning.


This was a relatively quiet day with people mostly sketching out ideas (whether in scribbles or words) independently. We shared and reviewed our ideas as a team at the end of the day, and the team began to embrace design.

The team were positive about our approach to idea generation, the pace we were moving at and the way we were working together.

Wall displaying post its and ketches
Our wall of ideas and sketches


We kick-started the day with an energising introduction from Jake and John, authors of The Sprint Book, on YouTube.

We made great pace, deciding on our best ideas and creating an end-to-end storyboard that we were ready to prototype.


Our front-end developer provided us with a solid foundation for a hi-fidelity prototype that users would be able to interact with.

Building a code-rich prototype didn’t mean the rest of the team were excluded from the day. Everyone played their part; building dummy data sets, mocking up paper artefacts, defining different scenarios. The whole team came together to create a situation that was as close to the real world as possible.

Laptop showing a coded prototype on screen
The prototype we created


We intended to test our prototype in a building across the road — this was the users’ natural working environment - and to stream the sessions over Google Hangouts via a laptop webcam to the TV in our room. This way the whole team could observe live and make notes. Apart from some technical glitches, the sessions went well.

We had a bit of time over lunch to make tweaks to the prototype for the afternoon, based on feedback from testing. It made sense to quickly fix them on the spot so they were no longer an obstacle for the afternoon sessions.

And that was it — in one week we had framed the problem, prototyped a coded solution, tested it with real users and got rich qualitative feedback we could act upon. Phew!

What happened next

We have since run 'show and tells' with people from policy and those in our wider digital hub and received positive responses. I’m keen to share our journey and inspire others to run their own design sprints.

Running a design sprint in government has its challenges: working openly, getting senior buy-in, cross-government dependencies, policy, legislation, funding... But don’t let that stop you. By the end of the week you will have tangible output in your prototype. You will have questions, but you will have answers too. You will have achieved a lot, fast, and this is just the start.

Read more about Charles' design sprint.

Sharing and comments

Share this page

Leave a comment

We only ask for your email address so we know you're a real person

By submitting a comment you understand it may be published on this public website. Please read our privacy notice to see how the GOV.UK blogging platform handles your information.