Digital Experience Toolkit

Be ready for Discovery

Before you start, complete all the pre-Discovery steps.

If you start Discovery before you’re ready, your team may experience obstacles or blockers. For example, an incomplete user research plan may need lengthy ethical reviews and approvals which may take up all the team’s Discovery time.

Kick-off session

A kick-off session is the first meeting your team will have. The session formalises the purpose of the team, common goals, objectives and roles.

Your whole team should be in the kick-off meeting, including subject matter experts, business owners and senior stakeholders.

Create a shared vision

In your kick-off meeting you’ll discuss the problem, including existing research and data about the service and the current user experience. You’ll also define:

• your vision statement and what you will do, you will continue to develop this as you go through each stage
• what success will look like at the end of Discovery, this includes things you want to understand and the artefacts you need to produce
• timeframes, milestones and reporting dates for stakeholders.

Set ground rules

During the kick-off meeting, your team will discuss how you will work together and create some ground rules. You should include things like:

• how you will work
• principles, values and team contracts
• communication and operation channels
• where and when you will hold team rituals like stand ups, planning sessions, showcases and retrospectives
• how you will keep track of the tasks you’re working on, for example you may use a kanban board or Gantt chart.

Define the user need

Your team will do research to get a deep understanding of the users and the problems the service aims to solve.

This will help you discover all kinds of user needs:

• current experience: what users are experiencing now and the products they use to complete their goal
• stated needs: the things users explicitly tell you that they need, for example they may need your service to be mobile responsive
• unstated needs: the things users expect your service to have, for example they may need information that’s easy to understand
• created needs: what users are forced to do because of policy or the way government works, for example they may have to use different online accounts for different stages of the same service
• actual goals: what the users are really trying to do when they use the service and its products, for example planning to travel, not just applying for a passport.

Include all users 

It’s important to speak to all your users. The research you do in Discovery may include:

• end users
• professionals, businesses and intermediaries
• public servants supporting service delivery and policy.

Get the background 

You will need to understand the existing business processes for this service. You’ll do this by using business process mapping. You may also need to consider: 

• technology that supports business processes
• how data flows through the service
• the policy intent for the service, so you can align this with user needs
• any obvious technical, legislative or other constraints relating to the service.

Create and develop artefacts

An artefact is an item produced during the service design and delivery process. It may be a user journey map, data model, prototype, design, diagram or workflow.

Example of artefacts you may develop:

• empathy wall: helps the team understand how real users get things done and their experience with current services and products.
• insight wall: shows people’s pain points using quotes that reflect their problems with current products and services.

Create a user journey map

The user journey map is the most important artefact in Discovery. The user journey map shows the steps a user must take to reach their goal, 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 and declare what you have earned
• work out what you can claim and send information to the government.

You will update your user journey map as you continue through the service design and delivery process.

Group pain points

Use affinity mapping to process all your research and create groups of pain points.

It will take at least 2 to 3 rounds of research to find patterns and common pain points. This will mark the halfway point of the Discovery stage.

Prioritise pain points

Bring stakeholders and your team together to prioritise pain points. You want to agree on 1 or 2 prioritised pain points to explore in Discovery, prioritising the value to the users over everything else.

Make sure you identify things the team will be able to deliver. There may be more than 2 that you can work on if they are not complex problems.

There may be 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 face. Find what will add the most value.

You can prioritise pain points with a matrix that ranks factors, such as:

• value to users
• value to government
• policy needs 
• technical feasibility
• inclusivity and access
• analytics, insights and metrics 
• if the problem is limited to the organisation.

Document your process

At the end of Discovery, it’s a good idea to produce a document or slide deck 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 pain points you heard
• the user journey map
• 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 start a knowledge kanban board. You will keep using this in the Alpha stage and beyond.

Measure performance

In Discovery, you should start thinking about how you will measure and report on your performance. Collect metrics that accurately capture your service’s ability to deliver the outcomes your users expect. This may include design standards, privacy and security, service performance and tasks completed by the user.

If you’re re-designing a service, you can build on what is already measured and reported. Set your team up with a good measurement framework:

• explore the analytics tools your organisation has access to and determine if they’re suitable for the type and volume of data you’re expecting
• work out the metrics currently being collected and record some 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.

Stopping at Discovery

Your findings may show that you don't need to continue the design and delivery process beyond Discovery. For example, if you discover:

• there’s no user need for the service you’re 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 and the team can move on to something else that will add more value.