Running a design sprint in government

In a week the team framed the problem and prototyped a solution to test their assumptions with real users.

I’m a senior interaction designer working with a multi-disciplinary team to help people prove things to government using APIs.

This is a story about a design sprint I ran. The focus is on what happened, rather than the problem we worked on. Sensitive projects are a reality of working in government, but we’re taking positive steps to make things open: it makes things better. This story is one of those steps.

What is a design sprint?

If you want to learn more about design sprints, there is a book.

The contents shouldn’t be new if you’re a team focussed on user-centred delivery. It’s the unique way in which these elements come together in just five days that make the Google Ventures process a great way to answer critical questions.

For an agile team, the term sprint can be confusing. Think of a design sprint like a design spike. You don’t need to assign your whole team to it. Think about what tasks can be held in the backlog until later and who you need to keep working on what’s left. Let everyone else focus on the design sprint.

Why run a design sprint?

We were working on a couple of projects that were waiting on other people to do something. Everyone was keen to add the next thing to our project board to stay busy.

The purpose of our team is pretty clear, so it can be easy to just start developing. But, this can be a problem too — we don’t want to spend time and money developing something to find out it’s not what was needed in the first place.

I wanted to run a design sprint to kickstart idea generation for the next project. The team weren’t sold on the value this would add considering our “scope”. After several attempts to convince the team to try it, they still weren’t bought into the concept — of course the designer wants to run a design sprint. In the end it took careful persuasion of just one person to help sway the decision — our delivery manager.

A design sprint was going to help us understand the problem we were trying to solve and get a good indication that we were on the right track. And — if we weren’t, we’d only spend a week finding that out, rather than months. It’s win win.

The design processes in a sprint are not all that different to what a team will go through during a discovery or alpha phase. The difference is the structured format and time constraints that force decisions and progress to be made. This makes running a design sprint a great thing to start or prelude a project, or to approach a new challenge midway through.

Before we started

We block booked a room for the week that would become our war room and rallied our troops. Our team was made up of a product owner, user researcher, business analyst, front-end developer and interaction designer (me).

I facilitated the week and we made our product owner our decider.

We invited a couple of experts along to join us. They are the ones that work with the existing problem and processes. They would be best placed to answer our questions and help us learn more throughout the week. Unfortunately, due to work they weren’t able to be released for the full week so we had them join us on Monday and Tuesday only which were the days they would be able to add the most value. We then saw them again on Friday for testing.

We also agreed that we would continue to attend the daily stand-up with the rest of the team, not only to make sure we were there to answer any questions, but also to update everyone on how the design sprint was going.

Monday

We framed the problem, setting a long-term goal and noting our biggest assumptions and questions down.

If we had followed the process strictly, we would have done a story map of what the future journey might look like after achieving our long-term goal. However the team found it difficult to visualise how this might work as there were so many elements that [in reality] were out of our control. This is common in government organisations — most services will interact with multiple departments and as a team you’re only empowered to focus on a thin slice of that big picture. In order to keep momentum going I asked the decider if we should focus on the current journey instead. This approach was favoured as we knew what the current journey looked like, so we could articulate and map it out. We also knew where the problems areas were.

This inverted approach meant that instead of picking a target moment in a idealistic journey, we kept grounded in reality and picked a point that was our riskiest problem and therefore our greatest opportunity.

It felt like a long day and I wasn’t sure that everyone was sold on the process [yet]. People had already questioned the value before we started and Monday’s process didn’t help. Whilst it’s an important day, it’s also a slow day that involved covering a lot of old ground. This was made harder by people from our wider agile team dropping in to observe from time-to-time, which meant more recapping. However, we got there and we were ready to start solving our target problem in the morning.

Tuesday

I always get nervous on Tuesdays (during sprint weeks). I know my artistic skills are below par and it won’t be long until my toddler son surpasses me in sketching ability. This doesn’t hold me back as I know it’s not about artistic prowess, but it can stop people from wanting to get involved. I have run workshops in the past that have fallen apart at this point because people won’t take part, lacking confidence in their ability to draw. But — it’s not about drawing something pretty, it’s about getting information out of your brain and down on paper. That information can be boxes, scribbles or even words. Words are perfectly valid sketches.

The process helps massage people’s confidence, as in contrast to Monday, Tuesday is a relatively quiet day with people sketching mostly for themselves. It isn’t until the end of the day — once we’ve honed our ideas individually — that we share and review as a team.

I didn’t need to worry as everyone was more than happy to get involved. It is a joyous feeling to see the team embrace design in this way.

At the end of Tuesday I held an impromptu retrospective. This was mostly to dampen my own insecurities that people were still pessimistic of the process. It was also a great opportunity to suggest anything that could be done differently.

As usual, I needn’t have worried — the team were positive about the fresh approach to idea generation, the pace we were moving at and the way we were working together. The excessive recapping from the day before was rightly raised and luckily no-one had dropped in today to observe. It was also suggested that we start the remaining days with a YouTube video by Jake Knapp and John Zeratsky who wrote the Sprint book.

Wednesday

As requested, we kickstarted the day with a short introduction from Jake and John about what we would get up to on Wednesday. They are infinitely more engaging than I am, so this was a great start to the days energy.

I could clearly see how the teams engagement had changed since Monday. Gone were the pessimistic stares from chairs. We were standing up and moving around the room in healthy discussion.

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

Thursday

We were spoilt — we had a front-end developer on the sprint team, with access to an Angular JS framework and could easily pull in GOV.UK elements and other code dependencies we needed. In minutes we had a solid foundation for a hi-fidelity prototype that users would be able to interact with like it was production ready. Getting the grunt work out the way with meant we had a full day to focus on getting the hard parts of our prototype right.

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. This would enrich the reality of the observations we would make during testing on our final day of the week.

Friday

The rest of the week felt like a marathon in comparison to Friday, which literally was our sprint finish.

We’d started with the intention of testing in the building across the road — this was the users natural working environment. We were planning to stream the sessions over Google Hangouts via a laptop webcam to the TV in our war room. This way the whole team could observe live and make notes.

The first session was due to start when suddently the WiFi wasn’t working on the test laptop. We couldn’t delay as we only had the participant for this time. I ran across the road with another laptop and pointed the webcam at the session half-way through. Unfortunately the angle wasn’t great and although the team could hear everything, they couldn’t see any of the interactions on the screen.

This was what came through on Google Hangouts. We had a bit of time before the next participant to set up. It wasn’t until after the session that we realised what we could see on the screen wasn’t coming through Google Hangouts at the other end. It was at this point we gave up on streaming and rearranged the afternoon sessions to be in the same room. This wasn’t ideal as it was no longer the “natural” environment, but at least everyone could observe.

We also had a bit of time over lunch to make a couple of tweaks to the prototype for the afternoon. A few obvious things kept coming up during testing that we hadn’t had chance to perfect the day before. It made sense to quickly fix them now so they were no longer a obstacle.

The afternoon sessions went much smoother and we affinity sorted all of our notes at the end of the day.

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

The following week, we did a show & tell with some people from policy. We shared the process we went through, what we built and learnt. We felt we’d done a great weeks work, but anticipated we’d soon be grounded back in reality. But again, worry was not needed! They were impressed with the process and what we had achieved in such a short space of time. They were even keen to find more ways in which our solution could be used.

This was a baby step in a long journey. We have learnt a lot, but most importantly we have learnt what we need to learn more about.

It turned out that the experts we had in the room were a niche subsection of the potential users, which means there was a lot we’ve potentially missed that could have led us on a different journey.

We’re planning to use the work we’ve done as part of a request for funding so hopefully this will become a full project soon.

I did a show & tell to people from our wider digital hub, to share our journey and hopefully inspire others to run their own design sprints. It was comforting to hear our product owner and front-end developer admit that they were skeptical beforehand — they didn’t believe we would do everything I said we would. Now that we’ve done it, they’re impressed with what we achieved and would do it again.

Running a design sprint in government has it’s own challenges: working openly, senior buy-in, cross-government dependencies, policy, legislation, funding. 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.