Discovery phase: the GDS way

In the past few months, I've been fortunate to work with some fantastic organisations in the public sector. But it's not been without it's challenges and working in the public sector means working under the Government Digital Services (GDS) framework.

It made me wonder about the differences between this framework and a traditional user-centred design process. We know we want to make the most out of it, below is my experience on how to do that:

Firstly, what is the GDS framework?

Government Digital Services (GDS) is a framework for agile experience design projects. The stages are: discovery, alpha and beta. These are not dissimilar from a traditional user experience design process, but with a focus on delivering a built solution from the user needs that is found through discovery.

So let’s examine the discovery phase within GDS. Here are the principles laid out:

• It should take 4 - 8 weeks

By the end you should have:

• A broad scope for the project
• A set of defined user needs written as user stories
• Decided what user stories need to be completed to build a minimal viable product

The clock is ticking...

The overall structure for a project is fixed by the recommended time frame (4-8 weeks), which is much shorter than the average discovery project (10-12 weeks). This means the onus is on the researchers to make sure they are working efficiently to get to the same answers in a shorter amount of time.

Because the only thing fixed is the end date, it allows the research activities to be more fluid and they can adapt techniques based on what the researchers think will get the best results, aligning to GDS’ agile standard.

This is different to normal projects because there isn’t a prescriptive statement of work to follow and a lot of our clients don’t currently work this way, so trust has to be built quickly. We tend to use techniques like stand-ups or show and tells to promote communication and to make sure all parties are kept up to date and informed.

Creating outputs that matter

With no statement of work, there is no responsibility to create research artefacts such as experience maps. These can, of course, be useful, but more as a strategic tool. That's not to say there aren't outputs though. Within GDS discovery the outputs can typically be: user stories, a to-be service blueprint and proposed systems diagrams.

Understanding your users, means that you know what problems they encounter with your service so you can define their needs as user stories. You can then map them out in a service blueprint that matches their mental model. This will inform the type of system or interface you will need for them to use your service as expected. This sets you up to be able to describe how and what you want to build in the alpha phase.

The benefit of knowing what to build is that you aren’t just creating research outputs that get shelved. You are making a plan to act on your research findings and ultimately improve your service through the delivery of a usable system.

Who needs this approach most?

GDS discovery projects tend to work really well for organisations who have large audiences with complex needs that interface with you through multiple touch points. Each of these audience groups will have a subset of needs (as well as common ones) with the overall audience. You will have to prioritise which ones are most important to them and for your service to be used.

This approach is also great when you are working with legacy systems that have become fragmented and have major issues with consistency and integration. The job here will be to understand how much of the content and functionality is still required and how much is obsolete. This knowledge is gained by speaking to your users, conducting in-depth interviews and getting them to showcase the problems they experience with the current system.

A real world application

The most recent GDS project I worked on was for the Department for Transport where we were tasked with investigating the performance of Street Works. In just eight weeks we managed to speak to people across 14 locations and surveyed 400 people, managing to discover and define eight audiences with 25 user needs.

The client was pleased how we were able to produce multiple high-level prototypes, including proposed legislative changes, that were validated with a segment of the original users we spoke to. This ensured that the features of the proposed new system could meet their needs. This provided the foundation for DfT to create a robust business case to apply for funding from central government for the alpha phase, which was approved!

What are your experiences of the GDS process? I’d love to hear from you.