The .gov.au means it’s official.

Australian government websites always use a .gov.au domain. Before sharing sensitive information online, make sure you’re on a .gov.au site by inspecting your browser’s address (or 'location') bar.

This site is secure.

The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

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 government services to get things done.

When designing 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.

Meeting the Digital Service Standard


How to recognise user needs


Traditionally, governments have looked at user needs from a policy perspective. From this viewpoint, they have seen them as things they can fix with technology.

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

For example, people experience several touchpoints with 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.

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 like website style or colour.

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 be used
  • 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.

Make the whole experience clear and simple for the user. You won’t meet their needs if you work on a single product in isolation.

How to learn about user needs


You can learn about users and their needs by:

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 cover them all 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. These 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, define all the different groups of people you need to include in your research by using information from:

  • existing research
  • subject experts
  • frontline 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:

  • 48 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 recruit 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

A wall with a lot of post-it notes and dot stickers.

Researching with people who don’t use digital services


Who to include in your research

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 have low levels of digital skill and internet access. 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 or may not have a computer.

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

And include people in your research who have high levels of skill. They may still need help with an online service if it is complex or they don’t trust it.

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 … (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 a personal 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.'

Focus 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:

  • sound like something a real user might say
  • 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 anyone who’s interested in your service, including colleagues, stakeholders, users and the public.

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 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

A poster showing the number of interviews and workshops, hours of interviews, team members participating, and locations/workshops that have happened in Discovery and also in Alpha stages. The numbers are recorded using post it notes.

User needs tend to be high level, broad in scope and stable 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.