Guidance‎ > ‎

A guide to discovery


This document was written to help delivery teams within the Defra group run successful discoveries. It might also be useful for other teams in other organisations.

It expands upon, and adds more detail to, the high-level discovery guidance provided in the GDS Service Manual.

It will take about 2 hours to read at a comfortable pace, with time to make notes. We encourage readers to export this document as a PDF, print it out, and read it offline.

It’s still a work in progress and we would welcome your comments. There may be things here that you might like us to change and improve - that’s ok. Please contact us, we’re happy to work with you to make it better.

Section 1: Understanding discovery

What discovery means

Discovery is a phase of work that helps a team understand and articulate a set of needs, and then propose a way of meeting them.

It allows the team to ask questions like “Who is this for? Why? What do they want to achieve?” … before they start to identify potential solutions.

It’s a useful process to go through before diving into any kind of delivery. It reduces the risk that you’ll try to deliver the wrong thing, and increases the likelihood that what you do deliver will work for its users, and bring about the outcomes you intended.

When is discovery the right thing to do?

Discovery is useful when thinking about:

  • needs that might result in a new or improved citizen-facing service

  • needs that might result in a new or improved internal service or platform

  • needs that might result in non-technical solutions (e.g. when exploring how you might do recruitment differently)

Discovery is just as valuable if you are likely to commission or buy a service as it is if you expect to build a solution internally.

This document is particularly aimed at teams working on things that might result in a new or improved citizen-facing service. It provides detailed guidance that can be followed by those teams. That said, the principles and techniques can also be applied in the other situations.

The benefits of doing discovery

Done well, a discovery process allows a team (and the organisation it sits in) to:

  • really understand the problems to be solved and the needs to be met (this includes understanding policy intent)

  • identify opportunities to meet those needs, potentially in new and transformative ways

  • if appropriate, propose an approach to incrementally deliver and test these opportunities (starting with an alpha if it’s a citizen-facing government digital service)

By involving a mix of subject matter experts and technical specialists, the discovery process helps to ensure that any solutions proposed are feasible and grounded in reality.

It also enables the people who might go on to build or run the service to be involved with shaping it, and should produce a roadmap that they are happy to support and deliver.

Teams intending to meet the government Digital Service Standard must start with discovery.

Although there is no formal Service Assessment at the end of the discovery phase, there is an expectation that services will have started with one, and this lays the foundation for many things that will be assessed, for example understanding user needs.

The Government Digital Service provides an overview of 9 key things you’ll know by the end of discovery. These are:

  • who your users are

  • your users’ needs and how you’re meeting them, or any needs you’re not meeting

  • which services currently meet your users’ needs and whether they’re government services or private sector

  • the policy that relates to your service and how it might prevent you from delivering a good service to your users (to put it another way: how policy might need to adapt to make the service better)

  • what the user journey might look like

  • how you’d start developing a new service if your discovery finds there’s a user need for one (or, how you’ll improve or iterate an existing service to better meet user needs)

  • how you might build a technical solution given the constraints of your organisation’s legacy systems

  • the people you need on your team for the alpha phase

  • what to name your proposed service

The risks of not doing discovery

In common with many of the other techniques in the government Service Manual, the discovery phase is a response to the cost and failures of previous approaches.

In simple terms, a common approach used to be to commission a solution up front, based on managerial assumptions or on what the market was selling. A delivery team (internal or external) would then work to deliver what had been specified, with very little opportunity to challenge or test the assumptions that had been made.

At worst, this could result in solutions that were actually impossible to deliver. In many cases it would result in services that weren’t intuitive to use by the intended users, and which failed to deliver the expected (assumed) outcomes.

Discovery is an opportunity to test those assumptions, and to really understand the people you expect to interact with. This increases the likelihood that any solutions you go on to deliver will actually meet user needs and successfully deliver realistic outcomes.

Discovery also decreases the risk that you’ll invest in a solution that’s not even needed. Sometimes, a discovery ends with the conclusion that no new services need to be delivered, or that the needs can be best met elsewhere. And that’s ok.

How long will discovery take?

There are no rules that say exactly how long it will take. The key things that affect it will be:

  • the scale and complexity of the problem/service that is being looked at

  • the availability/time commitment of the team

  • the availability of the Service Owner and SMEs for key workshops/discussions

  • how much prep has been done, and how thorough it is

  • the quality of any existing user research, and/or whether the user researcher can get instant access to users

Guidance from the Government Digital Service currently says:

“Every service is different, but depending on the size and complexity of your service, your discovery should usually take between 4 and 8 weeks.”

In reality, though, if you are looking at a transactional citizen-facing service, or an area of need that might result in one:

  • 4 weeks is very ambitious, even if all of these factors are in place

  • 6 weeks is a more realistic minimum, if you have a limited set of users and their needs are already fairly well known

  • 8 weeks is probably most realistic to understand the needs of multiple user groups and the issues/opportunities around an existing/legacy service


Section 2: How to prepare for discovery


Preparation work

Doing the right preparation up front will improve the success and efficiency of your discovery. It will also help you to secure the necessary funding.

The main focus is:

  • to gather material to be used and referred to in discovery

  • to make the case for discovery to be funded (including the people and skills needed)

Even at the prep stage, there should be an empowered Service Owner to lead and champion the work. It’s their name that should go on any proposals or funding bids.

They are likely to need support from one or more Business Analysts from their business area to help gather material and complete any required business case or funding request.

There are no digital/IT specialists involved at this stage.

Specific preparation tasks

These are the common activities in the run up to Discovery:


Prep activity

Things to bear in mind

Identifying the main business drivers

Why this service/policy area? Why now? What do we hope to achieve? How might this also contribute to wider programme or cross-Defra goals?

Gathering existing insight about the users of any current service and their probable pain points and needs

E.g. from customer service logs, performance data for existing online services, any recent surveys etc. You don’t need to be doing new research at this stage, just gathering what already exists.

Gathering existing insight about how any current service(s) in this area are delivered

Current policy, processes, technology maps, costs etc This could be expressed in As Is maps, but they don’t need to be polished at this stage.

Identifying subject matter experts who might get involved with Discovery

Put placeholder dates in their diaries and the Service Owner’s for kick off & other likely events

Making the case for Discovery and getting any necessary approvals

Don’t promise solutions at this stage! It’s about quantifying the problem/costs/issues that you want to look at. This will also need to include an understanding of the people and skills you are likely to need for discovery.


If you expect to be applying for funding for your discovery, the bodies you apply to will probably expect to see evidence of this work as part of you application.

Who will be needed in discovery?

Before you can start discovery, you need to make sure the right people and skills are available. Asking for these people is likely to be a key part of your business case or funding request.

The exact makeup of the team will depend partly on:

  • the scale of the service area you are looking at

  • the technologies involved (currently, and potentially in the future)

  • whether there is recent/current work being done on similar services, where expertise can be shared

However, in every case you will certainly need:

  • a senior accountable decision maker (the service owner)

  • someone to steer and shape the activities and outputs

  • someone to keep things moving and on track

  • user research expertise

  • service design expertise

  • technical expertise appropriate to your service (someone who can understand the current set up, and also someone who understands the wider tech strategy and future direction)

  • subject matter expertise (e.g. people who understand the policies and the current processes)

All of these skills will be needed - what may vary from service to service is who provides this expertise and whether they are full time, or working across more than one service.

If people are working across services (e.g. potentially a service designer or architect might) then the team will need to coordinate with the other teams to make this workable. E.g. they will need to make sure that their daily stand-ups and planning meetings don’t clash.

As a benchmark, a team working on a new service area with a dependency on technology would usually consist of:

  • Service owner / Service manager

  • Product owner / Product manager (if the service owner isn’t available full time day to day)

  • Delivery manager (if the Product Owner hasn’t done a discovery before)

  • Business analyst

  • User researcher(s)

  • Designer (with experience/interest in service design)

  • Technical lead(s)

  • Subject matter experts

You are unlikely to need either content designers or developers at this stage.

What will people be doing?

We’ll go into more detail in Section 3 below, but broadly speaking, during discovery, the purpose of each of the roles in the team is:

Service owner / manager

The service owner or service manager is the senior accountable person who is responsible for the service. They set the direction and make overall decisions about priorities. This role is essential and mandatory for any service working to the Service Standard. They need to be highly engaged and accessible to the team, and be available to attend all main events including regular informal gatherings like show & tells.

Product owner / manager

Unless the service owner is extremely hands-on they are likely to need a product owner to lead the team on a day-to-day basis, translating the business drivers and user needs into actionable tasks and plans, steering the process, setting priorities and shaping the outputs. Ideally this role would be filled by someone with professional product management experience. If the product owner does have previous experience of working through a discovery, then they could also be the person who leads the discovery process, keeping things moving and on track. In other words, if you have an experienced product owner, you may not also need a delivery manager for discovery.

Delivery manager

If the product owner doesn’t have previous experience of leading a team through discovery, they are likely to need a delivery manager to keep things on track, making sure they team has what it needs, unblocking issues, managing dependencies and logistics.

Business analyst

The business analyst is likely to lead or support a number of different areas including understanding and capturing process related insight and opportunities, stakeholder management and comms, supporting the production of the business case. They will work very closely with the product owner.

User researcher

Leads the analysis of existing user insight, and conducts new user research. They are the main champion of user need - but the whole team has to understand and be led by these needs.


At the discovery stage the main focus is on service design - including the production of a service map, with reference to any existing patterns. This is best done by a designer with a strong interest in service design. They may well have worked on, or be working on, other services in the same programme or service area. There is also a need for some high level work on potential future user journeys and user experience.

Technical lead

The technical work in discovery falls into two areas - understanding any current (legacy) technology already in use, and proposing future technical capabilities that could meet the user needs. Both will typically be done by a technical or solutions architect, but the team will also need access to an enterprise architect to ensure they’ve understood the overall and future technology context.

Setting up for success

In order to succeed, a discovery team ideally needs:

  • to be able to sit together, in a dedicated space

  • lots of wall space for thinking-out-loud

  • access to collaboration tools e.g. shared documents, a backlog tool like Trello or Jira

  • regular contact with the service owner

  • daily contact with the product owner

  • contact with users (internal & external)

  • the freedom to ask questions and challenge assumptions

Knowing when to start

You’re ready to kick off discovery when you have:

  • assembled the team

  • a clear purpose and set of business drivers

  • access to existing data & insight about any current service and users

  • any necessary approvals & budget

If any of these are missing or half-done, don’t start discovery. Get the preparation done properly first.

Section 3: How to actually do discovery

There’s no set way to do discovery

There isn’t a one-size-fits all approach to doing discovery, but there are certain principles and activities that are likely to benefit most teams.

This guide lays out one approach, developed by Defra, based on Sarah Prag’s approach, with additional input from elsewhere.

Over time this should be iterated, and illustrated with examples from real Defra teams.

There is also an emerging cross-government Community of Interest who intend to develop and share best practice for doing discovery. There are also some useful blog posts at the end of this document.

A suggested approach

The following framework can help teams to get to grips with discovery.

It breaks things down into 3 phases:

  1. Learning

  2. Sketching & testing

  3. Refining & planning

Discovery is a process. Teams move together, through understanding the problem, to identifying opportunities, to proposing a delivery approach. They open up their thinking before focusing in on an approach. For this reason discovery is sometimes pictured as a diamond shape.

The discovery diamond

What’s really important is the quality of the inputs to this process, and the quality of the conversations that the team have.

There are activities that will help this to happen - but just going through the motions and ticking off a checklist won’t deliver the transformative results. It’s about attitude, not just activities.

The approach laid out here assumes that the team are being asked to look at an existing service and identify ways to improve or transform it. This is a common scenario in government at the moment. Discovery helps the team to get back to first principles in terms of understanding users and their needs. However in parallel, the team are also looking at the current/legacy services and the opportunities (and constraints) this presents.

The important thing is to be lead by the user needs, not by the existing set-up.

Now let’s look at each of the three phases in turn.

The learning phase

This phase is about understanding the world as it is. The team’s focus is on research and analysis.

During the learning phase, the discovery team should aim to find out as much as possible about:

  • users & their needs (including other services they might already interact with)

  • business drivers & constraints

  • current internal processes & workflow (assuming there is already a service)

  • existing technology (again, assuming there is already a service)

In this period of information gathering, it’s important to try and avoid getting into discussions about how things could be done differently. The focus needs to be on asking questions about user needs, and about how things are now, and capturing the answers. This will provide the foundations for the next phase.

Here are some useful activities you can run during the learning phase:

Kick off workshop

This is an opportunity to:

  • Introduce the team to each other, including subject matter experts

  • Introduce everyone to the service, its vision, policy background, and drivers

  • Share what’s already known about the service (including what’s been gathered in prep)

  • Identify gaps in knowledge to be explored

  • Prioritise those gaps and create an initial backlog of work

  • Introduce ways of working (the backlog, the wall, standups etc)

Useful things to do in the workshop:

An intro icebreaker

  • There are various games etc that can be used at the start of a workshop

  • Whichever you use, encourage people to talk about what skills & knowledge they are bringing to the process, rather than their job title or where they sit in the organisation

An intro from the service owner

  • Why they have initiated a discovery, their vision for the service etc

  • Where this fits into a bigger picture. They may want to defer to the Service Designer or Enterprise Architect for some of this wider context

An intro to the discovery itself

  • What lies ahead, who will be doing what, opportunities to get involved

  • What you expect to produce by the end of the discovery

  • Potentially more detail on how the team will be working e.g. your Trello or Jira board, when stand-ups are planned, etc

A “What do we know?” exercise:

  • Put up a sheet or wall for each of the main areas: users & their needs, business drivers & constraints, current internal processes & workflow, existing technology. (If you are looking at an area of need without a current service then the focus will be mainly on who the potential users are, what is known about them, and what the business drivers are)

  • Taking these one at a time, ask the room what’s already known in this area: what are the headlines e.g. user groups, figures, issues, costs, technology used etc? What are the sources of insight (inc what has already been gathered as prep)? Capture the headline info on post-its on the relevant sheet/wall

  • Are there apparent gaps in what’s known? What are they? Capture them on different coloured sticky notes on the sheet/wall

  • Take photos of the sheets

A prioritisation exercise:

  • Take the sticky notes that represent gaps in knowledge

  • Ask: which of these should be looked into first? Why? By whom? What access or support might they need?

  • Create a prioritised list on the wall. This is your backlog for the sprint ahead

Gathering & mapping insight

The team should now be focused on plugging the gaps in knowledge identified in the kick-off workshop. Ideally they will be working from the backlog of tasks, held in Trello, or Jira or a similar tool.

This work will be happening in parallel with individuals working on their own specialist area(s) of focus but all bringing what they learn back to the team and sharing progress and any blockers at the daily standup.

The team will be using what they learn to build up a map of the world as it currently is. Ideally this will be on a physical wall next to where they are sitting, but it is also likely to be captured digitally. The service designer is likely to lead or supervise this work, with the rest of the team contributing.

It’s likely that only headlines can be mapped on the wall and that there will also be other supporting documentation.

The activities and outputs are likely to be:

Users & their needs

  • Lead by the user researcher

  • Likely to include both internal and external users, including those likely to need assisted digital support

  • Likely to involve new primary research i.e. contacting users, meeting/interviewing/surveying them to understand more about their needs and their current pain points. This is likely to be the most time consuming work in the learning phase

  • Also likely to involve analysing existing data or insight gathered during the prep phase (e.g. logs from the call centre, existing survey results etc)

  • The business analyst is also likely to be involved with this, particularly the analysis of existing insight, and perhaps supporting primary research with internal users. They might also be looking into other/existing services that meet or partially meet the emerging needs.

  • The designer is also likely to be involved with understanding and mapping the current user experience

The outcome should be:

  • Personas and names for each of the main user groups, probably brought to life with real quotes from the research

  • Overview of “epic” user needs (the high level needs picked up during the research); ideally these will be mapped on the wall

  • Overview of the current user experience, mapped on the wall

  • Overview of pain points, mapped on the wall

Business drivers & constraints

  • Business drivers & constraints should already be well known from the prep work, business case and kick off workshop.

  • However there may be things to follow up on or dig into (e.g. policy detail, the extent to which some of the obligations are really statutory)

  • You may also need to understand and map the costs associated with running the service (particularly if one of the business drivers is to find savings)

  • This is likely to be lead by the business analyst and involve the product owner

The outcome should be:

  • A set of overall Acceptance Criteria for the service can be a useful way to capture the main drivers & constraints (e.g. whatever we develop it must comply with regulation x, it must maintain £x revenue, it must meet the Service Standard, it must save £x, and so on)

  • Insights about business drivers & constraints are also likely to help explain process & workflow and be mapped as part of that e.g. if there is a statutory obligation to report something then there is likely to be a point in the workflow where this features.

Current internal processes & workflow

  • The detail of this is likely to come from the user research with internal users

  • However there will also be other sources (e.g. existing process maps)

  • The business analyst is likely to lead on pulling this together and plugging any gaps (including mapping the relative costs)

The outcome should be:

  • This will inform the process/workflow layer of the map

  • This is also likely to feed into the personas, for internal users

Existing technology

  • The tech lead will be focusing on gathering and understanding any existing technology through existing documentation, interviews, workshops etc

  • This is also likely to feed into the view of the cost of running the existing service

  • This assumes that there is already some technology involved in the service area If there isn’t, then the tech lead might focus on the wider technology context and potential candidate technology

The outcome should be:

  • This will inform the technology layer of the map, showing at headline level what tech is currently involved at each stage of the current service/process

  • There’s also likely to be more detailed background information about how things currently work, known issues, dependencies, contracts etc

As the team builds up a picture of the current situation on their wall it will become a powerful communication tool - not just for the team themselves but for any interested colleagues too. One of the benefits of working on a wall is that progress is very visible, and people can visit and be walked through what’s emerging. Its also a good idea to take lots of photos of it as it develops, they might come in useful later.

By the end of this phase the team will have:

  • A set of personas for external and internal users

  • A set of high level (epic) user needs for these users

  • A service map of the world as it currently is, showing the current user experience, underlying process/workflow and enabling technology, and flagging any pain points

  • A set of Acceptance Criteria for the service

Sharing, validation & prioritisation

The Service Owner and subject matter experts will have been involved in much of this work, and should also be able to view progress via wall. In addition, it’s useful to set aside dedicated time to walk through the outputs with them, for comment and validation.

You may want to hold a session mid-way through to validate your learnings, or you might hold a series of sessions with particular subject matter experts, in which they gather to review the parts of the map they’re most familiar with.

It’s important to have a session at the end of the learning phase to talk about prioritisation. This will help inform what you focus on during the sketching & testing phase.

Based on what you have learnt and mapped - are there any emerging priorities?

  • Are the needs of certain user groups higher priority than others? Why?

  • Are there particular pain points that need addressing more urgently than others? Why?

The sketching and testing phase

This phase is about identifying and testing opportunities.

It’s called “sketching” because this is about having lots of ideas and sketching them out in enough detail to be able to discuss and test them. It’s a collaborative process. It’s also the most creative part of discovery and can lead to the most transformational thinking.

How you approach it will depend partly on the scale and complexity of the service you are looking at.

Ideally, you’ll be able to look at a whole set of user needs - from trigger to goal. It’s best to start with a blank wall, and sketch out more than one way that the needs could be met.

It’s worth doing this even if you suspect that you’ll later need to focus in on one of the more limited or feasible options.

The main questions you will be asking and answering are:

  • if these are the needs of our users, how might they be met (better)?

  • what might be a great user experience?

  • what workflow does this imply?

  • what implications might this have for staff/partners?

  • what data/access to data does this imply?

  • what technical capability does this imply?

  • what candidate technology do we know about?

  • what savings might this generate (where relevant)?

Technical capability vs candidate technology

“Technical capability” means generic things like the ability to take payment, or for a user to log in, or to be able to send in evidence.

“Candidate technology” means actual named solutions that could meet these needs e.g. a particular payment system that’s already in use, a cross-government solution like GOV.UK Verify, or a document upload solution being developed by another team. This is where the team might need the input of an enterprise architect who is plugged into the wider tech landscape.

The value in separating these two things in your conversations and on your wall is that it makes you think about the capability first, and then consider a range of ways that could be met. This often helps when you come to build up your roadmap. Your first iteration might use a spreadsheet to store customer information, but a future iteration might use a full CRM solution like Microsoft Dynamics. The need remains, but the way that you meet it can iterate over time.

Starting with ideals

A good way to approach the sketching phase is to start with a blank wall, and map your user needs across the top before moving on down through the different layers (user experience, workflow, tech capability, data, candidate technology etc - using the questions above). You’ll be building up one or more versions of an ideal service map.

Ideally this will be a new map (or several), separate to the as-is service map that you made during the learning phase. The first map showed the world as it is, the new sketches shows the world as it might be.

The whole team should be involved with this process.

Ideally you would have a couple of goes at this, or play around with some variations. If you’re feeling really playful you can ask questions like “How would Apple do this?” or “How would Amazon do this?” Sometimes this can spark interesting new ideas.

Reality check

Once you’ve had a chance to think about a few idealised views of how the needs could be met you can turn back to your “as is” service map, the one you created during the learning phase.

How can you apply some of your new thinking to this? What opportunities might there be to move closer to the ideal? What steps could be cut? Where might better information help? What might you want to replace or reorganise? What new partnerships could you form?


Once you’ve sketched out some possibilities, think about how you can quickly test your thinking - with potential partner teams or organisations, with internal or external users etc.

At this stage it isn’t about formal user testing, but it is about sense checking your ideas with people outside of the core team.


Towards the end of the sketching phase you’ll need to prioritise opportunities to take forward into the final refinement and planning phase. If you’re working towards the digital Service Standard, that includes working out what you want to test in your alpha (see below).

Your Service Owner should have been closely involved with the sketching and testing, but you may want to organise a specific session to review what’s emerged, and to agree what to take forward. This could be done via a dedicated show & tell session.

In some cases, what may have emerged is that your organisation isn’t the best or right one to be delivering a service at all. You might have come up with some alternative approaches that involve partners or the private sector - that’s a valid outcome too.

Choosing an alpha

There are tips on choosing an alpha in the Service Manual.

Other things to consider:

  • Impact on users: will this make sense as an offer to internal and external users?

  • Scale: how many users will this reach? What potential future costs or savings might it lead to?

  • Opportunities to learn: what would we be able to test? What would we learn that we could build on? (Both for this service, but also for the wider programme)

  • Feasibility: do we have access to the necessary skills and technology to produce a meaningful alpha?

  • Pathway to beta: can we see a potential route from this alpha to a feasible beta and later, a live service?

The refining & planning phase

This phase is about coming up with a realistic plan for getting started.

In some cases this might be a plan for developing an alpha, internally. In other cases it might be a plan to procure a solution, or to initiate a new partnership, or simply to make some incremental improvements to a particular process.

In each of these scenarios you’ll still want to answer these questions:

  • What are we proposing?

  • Why?

  • What benefits will this approach deliver?

  • What funding do we need to take this forward?

  • Do we need to make a business case/complete a funding approval for this?

  • What are our dependencies and constraints?

  • Who needs to be involved?

Working towards an alpha

If the outcome of your discovery is that you are proposing an alpha, then you are likely to need to produce the following, as part of your refinement and planning work:

  • A backlog of high level user needs for the service

  • As part of the backlog, a set of user stories the alpha must address

  • A proposal/business case for the alpha work

  • A high level service roadmap

According to the Service Manual, discovery is finished when you know:

  • the scope of the service you want to build

  • whether to move into the alpha phase

  • the team of people you need if you do move on to alpha

  • that senior stakeholders want to begin building the service and understand your plans

  • how you’ll measure success and what a successful service would look like

  • any related services that exist to meet the user need and whether they’re run by government or third parties (your service shouldn’t be duplicating another government service and it should only meet needs government is uniquely positioned to deliver)

  • how many of your users need assisted digital support, and what their needs are

Section 4: further reading

Discovery for product managers in government, by Scott Colfer. This is a really good overview by someone who understands discovery and understands government.

Better discoveries, by Will Myddelton. Will writes thoughtful and thought-provoking stuff.

Three ways to run better discoveries, also by Will Myddleton.

Decoding discovery, by Matt Jukes. Matt does a good job of demystifying and simplifying the jargon.

Discovery from day one, by Dan Mutton.

Alpha to live is not a linear progression, by Michael Brunton-Spall: “Organisations should start many discoveries. Discoveries should lead to sometimes one, sometimes many and sometimes no alpha projects being started. Some of those alpha projects might lead to a beta service being produced and live services should come from the successful beta services.”

Discovering discovery, by Sarah Prag. “Not enough people actually begin at the beginning.”

ALPHA  This is an alpha release and will change in response to user feedback.

Originally written by by Sarah Prag; subsequent publication, updates and revisions by members of the Digital Working team.

Published under Open Government Licence.

Change log:

14 May 2018                           Copied to

22 November 2017 Google doc published to the web

18 December 2017 Feedback email address amended