Planning user research across design and delivery
As you move through the service design and delivery process, the research you do will change. Learn more about user research in each stage.
The needs and goals of the users define the service. You will uncover these needs and goals through your research in the Discovery stage and build on them throughout the service design and delivery process.
In all stages you will:
- do research with a broad range of users, including those with access needs and low digital skills
- think about the whole user experience, digital and offline, not just the product you are delivering.
In Discovery, you will do generative research, making sure you are designing the right thing. Later, you will do evaluative research to make sure you're designing it in the right way.
User research in Discovery
Before you start designing, learn about your users. Watch how users do things now and what problems or barriers they face. This is called contextual qualitative research. It will help you to understand how the service you’re designing can meet user needs.
Interview users
Interview and observe frontline service staff, if your agency has them.
This will help you understand:
- limitations of the current service
- how staff explain and resolve issues
- undocumented workarounds that people use to get things done.
Map the user journey
Create a user journey map to understand the user experience completing a task.
Don’t rely on assumptions the business has made. It’s important to do your own research to understand the user journey.
Examine existing data
To avoid bias, do your own primary research before looking at the research that exists. Existing research might include analytics, internal workflows and support logs. This can reveal issues and provide measurable evidence to support user behaviour.
Outcomes from Discovery
Once you complete your research, you'll be able to analyse your findings to gain insights.
In the Discovery phase you should:
- understand the problem you’re trying to solve for the user
- understand the touchpoints along the user journey, often expressed as a journey map, service map, mental model or alignment diagram
- create a clear set of needs and develop task models for different types of users
- understand the gaps, limitations and barriers for the user
- understand the opportunities for further research
- document user groups descriptions and characteristics that are significant for the service, often expressed as user profiles or personas combined with actual stories from user.
Complete Discovery research
You’ll have done enough research when you understand:
- who uses your service
- what users needs from your service
- how people with support and access needs interact with your service.
User research in Alpha
In the Alpha stage, try lots of different approaches to meet user needs and find out which approach works best.
The Alpha stage will help you reduce risks, including:
- design risks, making sure you have the right scope for the service
- business processes, finding out if government can build the service
- technical capability, making sure you can integrate the service and make it secure.
Work out what works, not what's popular
Be prepared to park any ideas that do not meet user needs. You may find different elements of an idea work. Take what is working and combine it with other ideas. Remember to document what you’ve tested so you can refer to it later. This helps the team remember what’s been tested and what hasn’t.
Do task-based testing so you can understand which version is most effective. Remember we care about what works, not the preferences people have.
You’ll know something works when people find it easy to complete a task. They will understand what they are doing and won't make mistakes.
Keep interviewing, iterating and testing
Once you have a prototype, even if it’s a paper one, you can start to test it with users.
You can see if your ideas will meet user needs and find out if the prototype is usable. You can use this insight to iterate your design and test again with users.
Combine prototypes tests with user research interviews. This will help you to deepen your understanding of user needs.
User research in Beta stage
In the Beta stage, you’ll learn ways to improve your service. Including different kinds of experiences users may have, including usability and accessibility issues.
There are 2 different research stages in Beta:
- Researching as you build the beta service.
- Researching with users of a working beta service.
Private Beta research
As you build out your Beta service, you'll continue to do task-based usability testing with a range of users. This time, you are aiming to refine a solution for launch.
When you do the task-based usability testing:
- decide on a hypothesis, this is how you think the design will meet a user need
- use a structured approach to evaluate, this will make it clear what work needs to be done
- test with people who have different needs.
Public Beta research
In Public Beta you will continue with your research and explore the information and data you gained from your public users.
In this stage you will conduct interviews and feedback from users and front line staff and do user shadowing.
You will also
- create 2 versions of the service to see which performs better, this is called A/B testing
- collect analytics and key performance indicators
- do audits including usability and accessibility tests
- collect operational data to measure service performance, such as customer service insights
- do follow-up interviews to collect detailed feedback from service users.
User research in Live stage
In the Live stage you will test and collect feedback to make sure your service meets user needs. These research activities will build your understanding of common issues to help you improve the service.
You can learn more about user needs through:
- web analytics and operational data
- surveys or follow-up interviews
- face-to-face and remote usability tests
- A/B testing on new and changed features.
The frequency and depth of the research you do in Live depends on what you are trying to find out. For example, you should start the Discovery process again before adding a new component to your service.