Search

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.

Team for the Alpha stage  

You’ll work with the same team in the Discovery and Alpha stage. This keeps the existing empathy, context and momentum.   

You may need to add some roles and capability in the Alpha stage. Such as: 

• business analyst 
• technical architect 
• delivery manager or similar, for example, scrum master. 

What to do in Alpha 

At the start of the Alpha stage, you’ll have a good understanding of the user journey and the major stages the user takes. As your knowledge grows, you will continue to work in an agile and iterative way, updating the journey map as you learn and understand more.  

When the team has some certainty about the journey of users, create a user story map. This will help you define the minimum viable product (MVP). 

In Alpha stage, you: 

• take your hypotheses from Discovery and create high-level concepts 
• continue to develop a vision for the service using your user journey and user story map 
• create storyboards to see possible solutions 
• create prototypes to test hypotheses with users, you should explore hypotheses with different kinds of prototypes, including paper and HTML 
• complete the stage by defining the minimum viable product. 

Decision register 

The knowledge kanban board you set up in Discovery is even more important in Alpha. It will help you trace your reasons for solutions and provide evidence to guide what you will build, including: 

• an explanation of the problem 
• empathy map 
• insight map 
• results of affinity mapping 
• pain points 
• hypotheses and concepts for solutions 
• user feedback and actions 
• decisions about direction or why work on solutions stopped. 

The knowledge kanban board should be saved and stored appropriately so it is discoverable to others in your agency and can be used for future reference once Alpha is complete. 

Service performance  

In Alpha stage you will need to decide which metrics you use to track performance so that you can meet Criteria 9 – Monitor your service. To do this you should: 

• have an analyst as part of your team, or available to your team, so you can start working out how you’re going to measure service performance 
• use your hypotheses to help you define your goals and benefits 
• develop a measurement plan that starts to define the metrics your service will report on 
• clearly define the start and end points for your service 
• engage with stakeholders to raise their awareness of your measurement plan and to decide the process for signing off and publishing the metrics. 

Activities for each sprint 

Each sprint, the team should: 

• hold a short meeting to prioritise user stories  
• conduct user research with at least 5 to 6 users who are representative of actual users of the service 
• capture learnings and insights from the research findings 
• showcase or share back to stakeholders to give them visibility of the prototypes and user research 
• have a team retrospective to reflect on the sprint and capture improvements. 

This aligns with Scrum methodology and helps keep the team focused on delivering something of value to users every sprint. 

Test with different kinds of prototypes 

Alpha is all about testing a hypothesis with real users. The best way to do this is by building and testing prototypes. Alpha prototypes are like a proof of concept. A prototype will not be functionally complete. It would be wasteful to produce a finished product before making sure it captures the most important and meaningful steps the user takes. Test with users using paper or other low-fidelity prototypes first. This allows you to test assumptions and ideas quickly and cheaply before getting attached to any solutions.  

Your team will decide which prototypes, if any, will be carried forward. From there you will update the prototypes based on feedback and test again.  

As you learn from your research, you will move on to testing with more interactive, higher fidelity prototypes. 

Create a good prototype 

A good prototype has enough information for users to interact and can be quickly adapted or thrown out. You may choose to re-use some designs or components when you build in the Beta stage but never confuse a prototype with a minimum viable product. 

It’s strongly recommended that you throw away prototypes that don’t work. Don’t spend too much time building prototypes, as you will build new ones based on user feedback. 

Low fidelity prototypes 

Some examples of low-fidelity prototypes include: 

• storyboards 
• card sorting. 

Low fidelity prototypes are an excellent first step as they are inexpensive, can be quickly updated or changed and are disposable. 

High-fidelity prototypes 

High-fidelity prototypes provide greater detail on the final product including the design. They’re usually introduced once low fidelity tests have been explored and the team has a stronger idea of how a service will work. 
 
There are some known downsides to high fidelity prototypes: 

• users are more likely to comment on superficial parts of a service, like colour, design and layout, rather than the content  
• they take longer to make and update than low-fidelity prototypes 
• they may give users a false idea of how the final service will look or perform. 

Tools to create high-fidelity prototypes 

There are many tools on the market you can use to build interactive, high-fidelity prototypes. These allow you to sketch in code, using HTML, CSS and JavaScript. Others work like web-builder apps allowing you to drag and drop buttons, images and sequence out a user experience path.  

Some teams have even used slide decks with basic animation to simulate an online service.  

Whatever you choose, remember: 

• show a seamless user journey that results in a positive user experience ‘ 
• include content and data that looks real 
• respond with alerts and feedback in the right places 
• make it look and feel like a real digital service 
• use familiar design patterns. 

Don’t support every browser 

Support a specific browser or version if a group of users or stakeholders depend on it. 

Users are likely to use the prototype in a controlled environment, such as a user research lab or on a team member’s computer. This means you need to support fewer browsers than a public website. 

Test for users with accessibility needs

As part of the user research, test your prototypes with users who have accessibility needs. Test with screen reader software and other assistive technology. 

Mobile first 

More users are accessing government services using mobile devices than ever before. If you design and build for mobile first, you can test prototypes in a more realistic context. To design for mobile, you should make a simple screen, with only 1 or 2 things on each page. This means users with larger screens will also have an easier experience. 

Define the minimum viable product 

By the end of Alpha, you will have a developed the user story map in depth. The team should agree on a line across the user story map. What is above the line should reflect what is most important for the user and what the team can achieve. This will inform your minimum viable product (MVP). This is the simplest thing you can build that meets the user need. 

The minimum viable product will scope what gets built in the Beta stage. The research and testing you have been doing in Discovery and Alpha will help you make choices about the technology you will use to build it. 

Decide if you will continue to Beta

End your service at Alpha stage 

You may decide to end your service work in Alpha stage rather than continue into Beta stage. 

For example, you may find that: 

• user needs for the service are already being met by another government service or the private sector 
• it costs too much to build the service based on the number of people who will use it 
• there’s a better non-digital solution 
• adapting or developing another service is a better solution. 

Start a new Alpha stage 

At the end of Alpha, you may decide to start a new Alpha stage or even Discovery stage because you need to focus on different things.

For example, you might find a completely different user need that you want to explore through further research.