Discovery stage: exploring the problem
Before you start designing and building, you need to understand the users and what they need a service to do.
The Discovery stage is when the Service Design and Delivery Process starts.
The purpose of Discovery is to get a deep understanding of what user's experience. It helps the team challenge their existing ideas of what the problem and solution might be.
This stage is for discovering, not validating. You won’t start prototyping and testing service design until the Alpha stage.
Meeting the Digital Service Standard
You must follow the service design and delivery process to meet Criteria 3: Agile and user-centred process of the Digital Service Standard.
The Digital Service Standard guides teams to build services that are simpler, clearer and faster.
Get ready for Discovery stage
Before you start the Discovery stage, make sure you:
- have the right roles in the team and understand how a multidisciplinary team works
- understand user-centred design and why we need to own the whole user experience
- understand agile delivery and how you will do budgeting and reporting when using agile
- find stakeholders and subject matter experts
- have all relevant reviews and approvals in place for your proposed research, have started your user research plan and are ready to start researching straight away
- understand the legislation, regulations and policies that may impact your service
- have an open space for the team to co-locate with internet access, IT systems and printers
- have purchased any equipment needed by the team (for example, laptops).
You need to do all of these things before you can start Discovery. If you don’t have everything ready to go, the team may be blocked for a long time. For example, ethical reviews and approvals on a user research plan might take several sprints of the team’s time.
What to do in Discovery
In Discovery the team does user research to understand the problems that users need to be solved. You will look at
- all the channels and touchpoints of the service (not just digital)
- the end-to-end user experience
- main user groups.
The team will need to understand the whole user experience and look at other related products and services delivered in their organisation.
To complete a service a user may have to interact with products and websites run by other teams. The user may also have to deal with other parts of government or commercial organisations.
The team should look at existing research done by other teams, but it is essential the team does its own research with users through all stages of the process.
Kick-off with the team
Start Discovery with a kick-off session that includes:
- the whole team
- subject matter experts
- business owners
- senior stakeholders.
The kick-off should include:
- a team-building exercise
- definition of roles
- sharing what you already know about the problem (including existing research and data about the service and the current user experience)
- creating a vision statement of what you will do — you will continue to develop this in the later stages
- a definition of what success will look like at the end of Discovery (the things you want to find out and the artefacts you need to produce)
- timeframe, milestones and when you will be reporting back to stakeholders.
During the kick-off the team should agree:
- principles, values and ground rules (this may become your team’s social contract)
- operating rhythm, including how long sprints will be and when you will hold team rituals (stand ups, planning, showcases and retrospectives)
- channels you will use to communicate
- how you will keep track of the tasks you’re working on (for example, a kanban wall)
- where you will work
- who will be working on what.
Do contextual user research that involves the whole team
The team will do research with users to get a deep understanding of the problems that the service aims to solve. They do this by finding out:
- who the users are and what they are really trying to do when they use the service and its products (for example, planning to travel, not just applying for a passport)
- what the current experience is for users and what products they use
- what the specific user needs are for the service.
You will discover all kinds of user needs, including:
- stated needs — the things that users explicitly tell you that they need (for example, they may need your service to be mobile responsive)
- unstated needs — the things that users take for granted that your service will have (for example, they may need information that’s easy to understand)
- created needs — the things that users are forced to do because of policy and the way government works (for example, they may have to use different online accounts for different stages of the same service).
The research you do in Discovery should include all users:
- end users, including professional ones (for example, businesses and intermediaries)
- public servants supporting service delivery and policy users — even if you are only planning to focus on a small part of that experience.
You will also need to understand:
- existing business processes associated with the service, by using business process mapping. This should include all teams and departments that are a part of the process or manage tools or resources used in the process.
- technology that supports business processes
- how data flows through the service
- the government’s policy intent for the service, so that you are able to align this with user needs
- any obvious technical, legislative or other constraints relating to the service.
The team will keep doing user research through the whole process, including after the service goes live.
Create and keep developing artefacts
You will create several artefacts and keep adding to them as you go through Discovery. The team will keep building and validating these artefacts — especially the user journey map — as it goes through the later stages.
An empathy wall helps the team understand how real users get things done and their experience with current service and products.
An insight wall shows people’s pain points using quotes that reflect their problems with current products and services, and what they are trying to do.
User journey map
The user journey map is the most important artefact you will start in Discovery.
The user journey map shows all of the steps that a user goes through to get what they need done, including their interactions with different parts of government and other organisations. For example, to lodge your tax return you need to:
- get your documents together
- declare what you have earned
- work out what you can claim
- send information to the government.
The user journey map needs to show the journeys of real users that you’ve met, not an ideal user journey. It is not a map of existing business processes.
Group pain points
You will know you are ready to move to the next step when you stop hearing new problems from users.
It will take at least 2 to 3 rounds of user research to start to find patterns in what you’ve discovered. This will mark the halfway point of your Discovery stage.
Use affinity mapping to process all of your research and create groups of pain points.
There may be kinds of pain points that only a small number of people experience. These are important, but you want to look for the big problems that most people are facing. Find what will add the most value.
Prioritise the pain points
Bring all the stakeholders together with the team to prioritise the pain points.
You want to agree on 1 or 2 prioritised pain points that you will explore in the second half of Discovery stage (for example, having to fill in the same information twice on different websites to apply for a passport).
Make sure you identify things the team will be able to actually deliver. There may be more than 2 that you can work on if they are not complex problems.
You can prioritise pain points with a matrix that ranks factors, such as:
- value to users
- value to government
- whether policy changes are needed
- technical feasibility
- analytics information
- level of effort for the team
- if the problem is limited to the organisation.
Prioritise value to users over everything else.
Develop hypotheses about the pain points
In the second half of Discovery, you narrow your research focus to the 2 pain points you have prioritised.
When you really understand the pain points, you will be able to turn your assumptions into meaningful hypotheses. These are what you will test with prototypes in Alpha stage.
Document your process
At the end of Discovery, it’s good idea to produce a document or slide deck that you can share with your stakeholders to explain how the team reached this point. This may contain:
- hypotheses you will explore in Alpha stage
- who you talked to and the pain points you heard
- the user journey map as you understand it at that point
- any pain points that are out of scope for Alpha stage
- justification of how you made decisions and the method you used
- current benchmarks of service performance
- how you will measure improvements to the service
- photos and feedback quotes.
You should also have started a decision register. You will keep using this in Alpha stage and beyond.
How long Discovery takes
Every service is different, but depending on the size and complexity, your Discovery should usually take between 6 and 8 weeks. A bigger problem will mean a longer Discovery stage.
In Discovery you should start thinking about how you will measure and report on your service’s performance.
If you are re-designing a service, this may build on what is already measured and reported.
Whatever measurements you consider, identify measurements that will help you understand the outcomes of the service, not just it’s outputs. For example, how did interacting with a service impact someone’s situation, business, or family? Rather than relying solely on the count of how many people use the service annually. Context for the numbers will help you understand the true value or impact of a service.
Complete the following work so that you have the right framework for the later stages:
- work out the pain points
- start to understand what a transaction looks like for your service
- find out what analytics tools your organisation already has and whether they’re suitable for the type and volume of data you’re expecting
- work out what metrics are currently being used and available, and record baselines
- find out where existing data for the service is kept and how you’re going to access it
- start thinking about additional data you might need that doesn’t currently exist or isn’t easily accessible.
Moving on to Alpha stage
You should move on to the Alpha stage if:
- you've stopped hearing about new needs and you’ve formed hypotheses about the most important of those needs that you can test in Alpha
- you’re confident that you will be able to build something that adds value
- you are working on needs that only government can meet
- you won’t duplicate other government services or products
- you have support from senior stakeholders and they understand your plans
- you know how you will measure success.
Stopping after Discovery
Your findings may show it’s best to stop at Discovery, for example, if you discover:
- there’s no user need for what you’ve been exploring
- user needs are already being met by another service
- technology or policy constraints mean you won’t be able to build a service in the timeframe.
It’s not a failure to stop developing a service after Discovery if your findings show that’s the best thing to do. The Discovery will still be successful because you will understand the problem better and the team can move on to something else that will add more value.