Focusing on meeting user needs is a key element of good digital work. Often technology projects fixate on “business requirements” over all else, and the experience of the end user is forgotten about.
This results in digital services and products that nobody wants to use!
Instead, a focus on understanding the needs of users and how they are best met results in greater digital uptake, which more often than not meets those business requirements we were obsessing over before.
What this looks like
- Talking to a diverse group of real users to understand their context and needs
- Designing for an entire journey – from the moment a need arises to an outcome being achieved
- Considering the needs of different types of users, how their needs differ, and how they may interact differently
- Testing things you have built with real users to see how well they work, and how they make your users feel
- Documenting user needs as well as business requirements
The questions
- Did you engage with real users to understand their needs and their entire end-to-end journey?
- Have you tested prototypes with a diverse range of users, including those with accessibility or digital support needs?
- Are evidence-based user needs clearly documented and balanced against your business and technical requirements?
How this links back to the Government Service Standard
This checklist point broadly maps across to:
Full guidance notes
User research is fundamental to developing effective, efficient, and inclusive public services. For local authorities, it moves decision-making away from internal assumptions and toward the real-world needs and contexts of the residents, businesses, and staff who use their services. By putting the user at the heart of the design process, councils can deliver services that not only save money but also genuinely improve lives and achieve policy intent.
This guide outlines the core principles and practices of user research, tailored for the context of UK local government.
1. Talking to Real Users to Understand Their Context and Needs
The golden rule of user research is simple: you are not your user. This means you must actively seek out and speak to the people who will actually use your services.
1.1 Why Research is Essential
Councils are experts in policy and governance, but the people who use your services are the experts in their own lives. They face challenges, have motivations, and navigate systems in ways internal staff may not realise. User research provides the evidence to:
- Avoid building the wrong thing: Don’t waste public money creating a service based on an educated guess that users don’t need or won’t use.
- Identify true pain points: The problem a service team thinks they are solving is often just a symptom of a much deeper, underlying issue the user faces.
- Understand real-world context: Where and when do users need your service? Are they using it on a phone while waiting for a bus, or on a computer at a library? This context is crucial for design.
1.2 How to Talk to Users
Qualitative research methods are key to understanding the ‘why’ behind user behaviour.
- In-depth Interviews: This is the bedrock of discovery research. Sit down with users (virtually or in person) and ask open-ended questions about their experiences, past behaviours, and how they currently achieve their goal. Focus on their actions and experiences, not just their opinions or what they might do hypothetically.
Tip: Always ask about a past specific instance rather than a future hypothetical one. For example: “Tell me about the last time you tried to pay your Council Tax” instead of “If you were going to pay your Council Tax, what would you do?” - Contextual Enquiry and Observation: Where possible, observe users in their natural environment—at home, at work, or while interacting with a council service (e.g., at a contact centre). This reveals the practical barriers, distractions, and processes they must navigate to complete a task.
- Analysing Existing Evidence: Look at the data you already hold: call centre logs, complaint records, website analytics (especially drop-off rates), and social media feedback. This quantitative data can tell you what is happening (e.g., people are struggling on a certain page), which you can then explore the why of through interviews.
1.3 Designing for an Entire Journey: From Need to Outcome
A common mistake is focusing only on the digital part of a service, such as a web form. In reality, a user’s interaction with the council is a complete end-to-end service journey. This journey begins the moment a need arises and only finishes when the desired outcome is achieved.
2. Mapping the End-to-End Journey
Your research must explore every step of this journey, including non-digital and cross-organisational elements. For instance, a resident needing to dispose of a large item might involve:
- Need Acknowledged: Realising they have an old sofa to get rid of.
- Information Search: Going to the council website, or phoning the contact centre, or asking a neighbour.
- Application: Filling in a digital form, making a phone call, or visiting a library.
- Payment: Making a payment online or in person.
- Preparation: Physically moving the item to the collection point.
- Collection and Outcome: The item being collected, and the resident’s goal being met.
Each stage has specific user needs and potential pain points. By mapping the journey, you ensure you are designing a complete, coherent service, not just a siloed digital component.
2.1 The Power of Service Blueprints
To aid this, create a service blueprint or experience map. This visual tool shows the journey from the user’s perspective, but also the council’s perspective—including the ‘backstage’ processes, systems, and staff involved in supporting the user’s journey. This makes it clear where internal inefficiencies directly create external problems for the user.
3. Considering the Needs of Different Types of Users
Local authorities serve everyone in the community, not just the ‘average’ resident. Services must be inclusive and accessible. This means actively researching the needs of a diverse user base, often referred to as inclusive research.
3.1 Identifying Different User Groups
User research must uncover how the same service need is experienced by different groups. Consider:
- Access Needs: Users with various disabilities (visual, auditory, cognitive, motor) will interact differently and may face significant digital and physical barriers. Accessibility must be a core part of your research, not an afterthought.
- Digital Exclusion: Users who lack digital skills, confidence, or access to the internet. They may rely on telephone, post, or face-to-face contact. Your service must work for them, too, often by supporting staff who serve them.
- Non-residents/Businesses: Users who aren’t typical residents, such as local businesses applying for licences, housing developers submitting planning applications, or charity workers supporting vulnerable people.
- Internal Users: Don’t forget council staff! Frontline workers, administrators, and inspectors are users of internal systems. Researching their needs is critical for efficiency and ensuring they can deliver a great service to external users.
3.2 Using Personas and User Profiles
To keep these diverse needs at the forefront of the team’s mind, you can create personas or user profiles. These are archetypes, based on your research data, representing significant groups of users with distinct needs. For instance, you might have:
- Digital Dan: Tech-savvy, wants to complete the task quickly online.
- Supportive Sue: A relative or friend helping a less digitally confident person.
- Non-digital Neil: Lacks confidence or internet access and prefers to use the phone or visit in person.
By constantly asking, “Does this design work for Neil? Can Sue easily help another person?”, you build a service that truly is for everyone.
4. Testing Things You Have Built with Real Users
Once you have a better understanding of user needs and have started to design a solution, you must test it. Usability testing is about seeing if what you have built actually works for the people it’s intended for, and how it makes them feel.
4.1 The Iterative Testing Cycle
Testing should happen early and often, even on low-fidelity prototypes.
- Prototype Early, Test Often: Start testing with rough sketches or simple paper prototypes (in the Alpha phase) and progress to more refined, working prototypes (in the Beta phase). It is cheaper and easier to fix a problem on paper than it is once code has been written.
- Usability Testing: Ask real users to complete key tasks using your design. Observe what they do, where they get stuck, and what they say (or don’t say) when they encounter problems. This is about seeing if the service is intuitive and easy to use.
- Measure Feeling and Trust: Public services often involve emotionally sensitive issues (e.g., housing, social care, bereavement). The language and tone of a service are as important as its functionality. Testing should reveal if users feel confused, frustrated, anxious, or reassured by the language and design. A service must be clear, transparent, and trustworthy.
4.2 The Value of Team Observation
Ensure that the entire team—designers, developers, product managers, and even policy makers—observe research sessions. Seeing a real resident struggle with a service is far more impactful than just reading a summary report and builds crucial empathy within the team.
5. Documenting User Needs as Well as Business Requirements
For user research to influence a project, its findings must be captured and documented in a way that is actionable and shared across the organisation. This is about making sure user needs are given equal weight to internal or legal constraints.
5.1 The Format of a User Need
A user need is a statement of what the user is trying to achieve. It should be based on evidence from your research, not assumptions. The standard format is:
As a [type of user], I need to [do something], so that [I can achieve an outcome].
Examples:
- As a new resident, I need to understand the different services the council provides, so that I know how to access support for my family.
- As a small business owner, I need to only enter my business details once, so that I can save time when applying for multiple permits.
5.2 Integrating Needs with Requirements
It’s vital that user needs are not treated as a separate document but are directly linked to the development work.
- User Stories: The service team converts high-level user needs into more detailed user stories that define a specific piece of functionality (e.g., “As a resident, I want a map showing my bin collection dates, so I don’t miss a collection”).
- Business Requirements: These cover the non-negotiable constraints, such as legal or policy mandates (e.g., “The system must integrate with the existing finance platform”).
By documenting both, the project team can clearly see how they are meeting the user’s requirements while operating within the council’s legal and business constraints. The tension between these two requirements often drives better, more innovative solutions.
5.3 Sharing and Reusing Research
Local government across the UK often faces similar problems (e.g., managing planning applications, applying for parking permits). To avoid costly duplication, local authorities should make an effort to share their research findings (anonymised and respecting privacy) with other councils, perhaps through the Local Digital collaboration initiatives.
By embedding user research throughout all phases of service development—from initial discovery to live continuous improvement—local authorities can ensure they are designing services that are simple, clear, and truly work for the public they serve.