The better you understand your users, the more likely you are able to design and build a service that works well for your users.
Who are our users? They are people who need to use the services you are working on. When designing, 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.
How to recognize user needs
Traditionally in government, user needs are identified when policies are written. Services are designed based on this policy. This results in a large gap between the understanding of user needs for the design, and the understanding of those needs for the design of services.
For example, people experience several incidents 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.
Following are some of the ways you can use to make your research better:
- 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.
- Who to include in your researches
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)
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.
- 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 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.
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.
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.