Search

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. 

The team you need in Beta 

The multidisciplinary team you established in Alpha should stay on in Beta. This keeps the existing empathy, context, and momentum. You might need to bring in different roles and capability during Beta.

These may include: 

• web operations expert
• ethical hacker 
• data analyst. 

What to do in Beta 

In Beta you will take the agreed prototype from the Alpha stage and build a minimum viable product.  

The main activities in Beta are: 

• development 
• design 
• usability research 
• accessibility testing 
• metrics monitoring. 

Private and public Beta 

You will release in private Beta, testing in short rounds as you continue to update and iterate. As your team refines the product, feedback rounds will become shorter. Continue running the private Beta until you have a functioning end-to-end service. Once you have a functioning end-to-end service, you can open a public Beta people can use alongside the existing service.

As real users trial the new service you will continue testing to find ways to improve it. 

These activities help you: 

• build your service and plan for its launch 
• solve any remaining technical or process-related challenges 
• improve your service by testing it with users and releasing updates. 

Update artefacts 

The team will continue to update the artefacts developed in the previous stages. This includes: 

• vision 
• user journey 
• user story map 
• decision register 
• prototype. 

How to work in Beta 

In Beta the team should build the real thing with the minimum features that support the end-to-end user journey. Make it accessible and secure. Avoid the temptation to build a polished version of your Alpha prototype. 

During Beta: 

• make sure the team’s focus switches from experimentation to prioritising the minimum viable product 
• work as a team on actual user stories – make sure you focus on needs, not wants 
• define and iterate a workflow, including ‘definition of done’ and other details to help the flow and work through the backlog of items. 

Use Agile Delivery practices

Your team should use agile delivery practices, including: 

• continuous iteration and delivery 
• test-driven development  
• automation 
• incremental design 
• pair programming. 

Release a private Beta and public Beta 

Once you build the minimum viable product you will release it to real users, first as a private Beta and then a public Beta, alongside the current service. Your research will help you find the best way to host the new public Beta. This might be a new subdomain, sub-directory or a domain name. 

Apply for a new domain name through the gov.au Domain Administration System. 

Private Beta 

A private Beta is a Beta that isn’t open to everyone. Don’t launch your service publicly in private Beta, make it invite-only. A private Beta allows you to: 

• have control over the users who test the Beta service 
• restrict the volume of transactions that go through the Beta service 
• start small and get quick feedback before releasing the service out to a wider audience. 

Public Beta 

A public Beta is a version of your service that’s available for any member of the public to use. It will exist at the same time as the current available service. This version of the prototype is available to all users, should they choose to use it. 

Measure performance 

You need to measure and report on the performance of your service. You will: 

• put the measurement plan from Alpha into action, this means integrating your APIs, setting up your analytics and so on 
• test the outcome of the plan with stakeholders 
• iterate and improve the plan, consider sustainability over time and only collect the information you need. 

Performance metrics help you understand if your service is meeting user needs and allow you to make decisions based on evidence. During Beta, you will: 

• capture real performance data for your service 
• iterate and improve your service through findings 
• improve your methods to capture data, where needed 
• plan how you will maintain your data and keep data records tidy. 

How you know Beta is finished 

At the end of Beta, you will have: 

• launched a private Beta service followed by a public end-to-end service 
• built a working system that can be used in full
• made a prioritised list of work to be done
• made a plan for ongoing user research to compliment quantitative data. 

Make sure you plan how you will meet resourcing needs when the service scales up. 

Your multidisciplinary team should stay in place when the service goes Live to make sure it continues to be iterated and improved. 

Finding the right capabilities 

You will need to have specific roles and capabilities in your multidisciplinary team before you start Discovery.  

Core roles 

There are 10 core roles to consider when building a multidisciplinary team. The core roles in a multidisciplinary team are consistent from discovery through to Live. 

The same core roles should be in the team for all 4 stages of the service design and delivery process. Find out more about the function and purpose of these core roles in a multidisciplinary team. 

Core roles allow you to: 

• design and deliver a service that is simple, clear and fast 
• make sure your team has the right capabilities, skills, knowledge and attributes throughout the life of the service. 

Extended roles 

An extended role refers to when you may need specialist expertise to join the team for a time. For example, you may need the role of content strategist at the start of designing a service, but not for the whole service. 

How to structure your team 

Start with a user-centred approach. Think about what you need to design and deliver to meet user needs. Different types of products and services will determine which of the core roles you need. 

Put users first 

Seek to understand user needs.  Build your multidisciplinary team around a problem or service. 

Understand the roles 

Understand what the different core roles are and what they do. You can then decide which roles you need in your multidisciplinary team to develop the product or service your agency needs. 

Decide when you need the roles

Decide when you need the roles. This will depend on the type of service you’re designing and delivering. Once you decide which core roles you need, they will stay in place for the life of the service. For example, if you are designing and building a service, you will likely need all 10 core roles. If you are designing policy or legislation, you may not need a developer or a technology lead. 

Roles you'll always need 

You will always need the core roles of product manager and user researcher, as these are foundational to any service. Try to make sure that your core team is also empowered to make decisions. This will help them move through the service design and delivery process as smoothly as possible.