Understanding users and their needs

The better you understand your users, the more likely you are to design and build a service that works well for them.

Who are our users? They are people who need to use the services you are working on. When designing or iterating a government service, start by learning about current and future users. 

If you don’t understand who the users are or what they need from your service, you can’t build the right thing.

[TOC]

Meeting the Digital Service Standard

You must do user research when designing and building your service to meet the following criteria:

• Criteria 1: Understand user needs
• Criteria 3: Agile and user-centred process
• Criteria 9: Make it accessible
• Criteria 10: Test the service
• Criteria 12: Don’t forget the non-digital experience
• Criteria 13: Encourage everyone to use the digital service

The Digital Service Standard guides teams to build services that are simpler, clearer and faster.

How to recognise user needs

Traditionally in government, user needs are identified when policy is written. Services are designed based on this policy. This results in a large gap between the understanding of user needs for the design of policy, and the understanding of those needs for the design of services.

Our way of working asks government to look at our services from the users’ perspective.

For example, people experience several touchpoints with different areas of government when they travel overseas. They may need to get a passport, check travel warnings or register their travel details. All these add up to an entire service from the user’s perspective, despite being accessed from multiple different government agencies.

When doing user research, we recognise user needs by focusing on people’s goals rather than their preferences. Goals are the things that they need to do. Preferences are things they may want or like, such as website style or colour.

A common misconception is that people are coming to interact with a website, when in fact they are often coming to access a service.

People interact with services, not websites. They use our digital services when those services are simple and fast.

Design to meet user needs

Services designed around user needs:

• are more likely to allow the user to complete the task they are trying to do, without support
• help more people get the right outcome, achieving government's policy intent
• cost less to operate by reducing time and money spent on resolving problems

The current experience of a service might involve interacting with different products that may be owned by different parts of government. The service you are designing and building needs to meet the whole user experience with those products.

This makes the whole experience clearer and simpler for the user. Often you won’t meet their needs if you work on a single product in isolation.

Think about the whole service, not just a product.

How to learn about user needs

You can learn about users and their needs by doing the following types of activities:

• interviewing and observing actual or likely users of the product
• talking to people who work with actual or likely users
• reviewing existing evidence

Treat any opinions or suggestions that don’t come from users as assumptions. Explore these in your research.

Keep researching through each stage of the design and delivery process to make sure your service continues to meet user needs.

Who to include in research

Groups to consider including in user research are people who:

• currently use the service
• don't currently use the service but may need it in the future
• have problems using the service
• work in the service (for example, call centre staff)
• help others use the service (for example, caseworkers, legal professionals or charity workers)

When researching, focus on users who have problems using the existing service and its products. This will help you create a simpler, clearer and faster service that more people can use.

Research wide then go narrow

For government services, it’s best to start wide and then narrow down your user research.

Begin by looking at as many different users of your service as possible. That way you’ll see the entire spectrum of users, from the mainstream to the edges. You should aim to speak with as many of your user groups as possible in the Discovery stage.

The mainstream users will show you what business as usual is for your service. You’ll see why they are using products and how they are managing the processes.

At the extremes, you'll see the groups of people who may be finding it difficult to access your service. You’ll find out their current pain points as well as what is working well about the service. These pain points might include things that are pushing them out of your service. For example, they may find the service too difficult to navigate.

Other users might have workarounds for accessing your service. For example, they might use websites to translate content into their preferred language.

Build the service so that it works for the people with the most barriers to accessing it. That way, you can be sure you’re building it for everyone.

Define your participant criteria

First, brainstorm the different groups of people you need to include in your research by using information from:

• existing research
• subject experts
• front line staff
• service data
• analytics
• general population statistics
• user groups that may have different experiences when using your product
• user personas (if available)

When you've defined your overall criteria, decide which groups you will include in each round of research.

Specify target groups

Depending on your research objectives, your criteria might be:

• a particular demographic (for example, women under 30 years of age)
• a specific user group (for example, small business owners or job centre staff)
• specific life events (for example, users who have recently moved home or are looking for a job)
• specific access needs (for example, people who use assistive technology)
• a specific level of digital skill (for example, users who have basic online skills)

Ask subject experts for information about target groups. They may know about groups that you haven’t already included. They may also help you to get in touch with people who need extra support to take part in your research.

Review your participant criteria to make sure they are relevant to your research questions. Do a gap analysis to make sure you don’t miss important groups.

Outside of any specific criteria, always try to recruit a representative spread of:

• age
• gender
• social and economic status
• cultural and linguistic background
• education level

The research methods you use will determine the number of participants that you need. For example, you’ll need:

• 4–8 participants per round of user research
• more than 250 participants for benchmarking

Make your research inclusive

You need to learn about all your users to build a good service. Find out about people with access needs or who don’t currently use digital services.

Make sure you don’t exclude any users in the way you do research. Recruit participants that reflect the population and choose accessible research locations.

Recruiting participants with access needs

You must conduct research to understand the experience of people with disability. Make sure you find out their needs ahead of time so you can make sure they can take part. For example, they might need to:

• bring someone with them
• use assistive technology
• bring a service dog

Diversity in user research

‘We used a physical wall to keep track of who we had spoken to. Each time we did user research we stuck a dot on the user group we’d spoken to. It’s a quick way to make sure we’re seeing a wide range of people and to keep track of who we still need to talk to.’ — User researcher.

Researching with people who don't use digital services

Who to include in your research

You should conduct research with people who have a mix of digital skills. It is important to speak with people who have a low level of skill as they will help you understand support needs that are the most difficult to meet. For example, some users may not be able to leave their homes, may not have a computer or may live in an area with very poor internet. It is also important to conduct research with people who have a high level of skills. They may still need support with an online service or may have concerns about privacy and security.

When you’re researching with users who don’t or can’t use digital services you should focus on the people who are current users of your service or who are likely to use it in future.

Include people in your research who get support to use digital services. For example, they may get help from carers or support workers.

Things to remember when doing research

When carrying out your research, remember to:

• explore users’ digital support needs across all channels (including online and offline)
• hold the research in places where users use the service (for example, if they need to go to the post office to get support, do it there)
• talk to users rather than relying on the opinions of third parties
• don’t rely on self-assessment of digital skills — wherever possible, get them assessed by an expert user researcher
• show the on-screen service to all users so they can give you accurate feedback on the support they would need
• find out the places where users seek support, including government contact centres, libraries, friends and family, trade bodies, paid intermediaries, charities or colleagues

Share what you know about users

Once you’ve learned about the different kinds of users of your service, present your findings. Do it in a way that’s easy for others to understand and share.

You can present your findings by creating:

• experience maps that show how users interact with existing services
• user profiles that describe groups of users with similar behaviours and needs
• case studies that explore individual experiences

Writing user needs

Once you have a good understanding of your users’ needs, write them down. You can then add them to your descriptions of users.

User needs are usually written in the format:

• I need/want/expect to … (what does the user want to do?)
• so that … (why does the user want to do this?)

You can add:

• as a/an … (which type of user has this need?)
• when … (what triggers the user’s need?)
• because … (is the user limited by any circumstances?)

Write user needs from the user's perspective. Use words that people would recognise and use themselves. For example:

'As an Australian I need a passport so that I can go overseas and prove who I am.'

Prioritise your user needs by focusing on what’s most important for your users so you don’t create an unmanageable list of user needs.

Validating user needs

User needs should:

• be described in the user’s words
• be based on evidence from user research, not assumptions
• focus on the user’s problem rather than possible solutions

As you progress through the service design and delivery stages, confirm and refine user needs.

Show the user needs

You should share your users’ needs with everyone in your service including colleagues and stakeholders.

When presenting user needs, it can be helpful to group them by:

• audience, user type or persona (for example, new parent, caseworker or small business)
• stage in a process (for example, register, apply or interview)
• function (for example, identity, payments or licensing)

The more you share, the more people will learn about your users and what they need from your service. They’ll also ask questions, spot gaps and comment on what you’re doing. All of these will help you iterate your user needs and ultimately design a better service.

User research dashboard

‘We have a user research dashboard because it’s a big priority for our team. To make sure everyone is out there doing research regularly. It helps us make sure we are focusing on meeting user needs.’ — Developer.

Link user needs to user stories

User needs tend to be high level, broad in scope and stay the same over time.

As you design your service, you’ll use them to write user stories. These describe the specific features and content you need to create for your service.

User stories are normally written in a more constrained format than user needs. They include additional information like acceptance criteria, level of complexity and dependencies. Teams use them to organise work into manageable chunks that create tangible value.

When writing a user story, you should keep track of the user needs it relates to. This allows you to track related activities and assess if you’re meeting user needs.