Discovery stage

Before you start designing and building a service, you need to understand the problem that needs to be solved.

This means learning about:

• your users and what they’re trying to achieve
• the government’s policy intent for the service, so that you are able to align this with user needs and existing business processes associated with the service
• technology and system architecture that supports these processes
• how data flows through the service
• any obvious technical, legislative or other constraints relating to the service
• opportunities to improve things (for example, by sharing data with other teams).

# What to do in Discovery stage

What you learn during Discovery should help you work out whether you want to move forward to the Alpha stage. Running an Alpha means you’ve decided that the benefits of looking further into the problem outweigh the cost.

# Discovering - not designing or building

This stage is for discovering, not validating. It’s not about coming up with a solution straight away.

You won’t start prototyping and testing service design until the Alpha stage.

It's not just about a single system of interaction - it's about learning about the whole service.

# Allow 6 to 8 weeks

Discovery stage usually takes between 6 and 8 weeks. But every service has different size and complexity: a bigger problem will mean a longer Discovery stage.

# Setting a goal

It’s useful to start by setting a clear goal for your discovery. This will help you scope your discovery appropriately and work out when it’s finished.

# Defining the problem

At the start of Discovery, you might be presented with a pre-defined solution or told you’re building a specific thing. You’ll need to interrogate that solution and reframe it as a problem to be solved. This will help you better understand what your team has been set up to achieve.

Start by defining the problem you’re working on. The better you define it, the better the potential solutions you’ll end up with if you move on to the Alpha stage.

Break down assumptions and ask lots of questions.

Reframing the problem also includes agreeing what is not part of the problem.

You should also understand how much the problem is currently costing the department and our users.

# Understanding users and their context

We start by learning about the users and their context. This means understanding what the user is trying to achieve and how they go about doing it.

You’ll often find that your service is part of a bigger process or user journey (for example, accessing and rectifying a Corrective Action Request (CAR) is part of the larger audit journey).

Start by seeing what existing research has been done. Refer to our research library to see what research has been done in our Department so we don’t duplicate efforts.

Do user research with users to understand their current experience. This includes:

• end users, such as exporters/establishments
• department staff supporting service delivery (such as auditors, veterinarians and inspectors).

You’ll also need to learn about your users’ accessibility requirements.

You will need to plan your user research approach. There are many ways to approach researching your users.

We recommend doing contextual research with people in their real-world environments.

Involve the whole team in the research and analysis so that the entire team is developing a deep understanding of your users and of the ecosystem. This will help to enable better and faster decision making.

# Mapping the user journeys

Informed by the user research, there should be an ongoing process to begin mapping out the user journeys. It’s important that these are journeys of real users that you’ve met, not an ideal user journey or a map of existing business processes.

This starts in a low-fidelity form, on a whiteboard or on paper, and gains more detail throughout the course of Discovery.

By the end of Discovery, you should have a comprehensive map of users and their interactions with the department (and potentially other organisations too) as they use the service.

It’s then possible to map the user research, touch points, pain points, and existing technology against their user journey.

# Understanding how the business works

Doing research with internal users in the organisation will help discover some of the internal pain points with current processes and give insight into the viability of potential options for Alpha.

This can include:

• business process mapping
• listening to calls to call centres, and observing how staff respond to them
• visiting shopfronts, where parts of the service are provided.

From this research you may wish to map the internal user journeys of staff dealing with the users of the service. This will give you a better understanding of how staff support the service end-to-end, and highlight the systems that they interact with.

# Mapping the technology and data

Understanding the existing IT systems, data stores and in-flight programs of work will give the team greater visibility into how Alpha opportunities could fit into the existing technology landscape, and inform the longer-term roadmap for the service.

You will need to identify and map the technology and data landscape, reusing existing capability and knowledge in the department.

Mapping these systems, data and responsible agencies against the service map will give the team a complete view of where user needs are currently being met by technology.

# Artefacts you may produce

You will create several artefacts and keep adding to them as you go through Discovery.

The types of artefacts you produce will vary depending upon what you need to document and communicate. The team will keep building and validating these artefacts — especially the user journey map — as it goes through the later stages.

Some suggestions of artefacts you might produce:

• User needs - a well documented set of user needs, informed and evidenced by the user research you have completed.
• User journey map - 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 DAWE and other organisations.
• Service map - the service map is created from the user groups, as a map of the wider problem space. It includes the users, business, technology and data for each stage of the service.

# Finishing Discovery stage

At the end of the Discovery stage, you’ll have a good understanding of the user’s needs, and the service landscape.

# Identifying hypothesis

You should use your understanding of the users their needs and context to formulate your hypothesis. Your hypothesis should define the target state for your service.

By defining your hypothesis in the Discovery stage, you give yourself the opportunity to test what you think the solution to your problem is before developing the actual solution.

During the Alpha stage, the hypothesis will be tested with a number of possible solutions.

# Sharing what you learn

At the end of Discovery stage, you should report back on your findings in a discovery document. This can be shared with senior stakeholders and across government.

Produce a document or slide deck that you can share with your stakeholders to explain how the team reached this point.

The deck 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.