A Practical Guide to Discovering User Needs

Who this guide is for

Use this exercise when a team receives a request such as “Build a dashboard” or “Send more reminders”. It helps business analysts and project teams explore the reason behind the request. The example below is fictional.

1. Record the request without treating it as the answer

A training administrator asks for a new attendance dashboard. Write down the request, who made it and what decision they expect the dashboard to support. Ask what currently happens when the information is missing.

2. Separate what you know from what you assume

Create two lists. In the evidence list, record observations and their origin. In the assumption list, record statements that still need investigation. For example, “Staff cannot identify incomplete attendance records” remains an assumption until you examine the process or speak with the people doing the work.

The GOV.UK Service Manual recommends grounding user needs in research evidence and focusing on the user problem rather than a selected solution. This guide applies that principle to a small fictional workplace exercise.

3. Speak with the people doing the task

Use open questions: “Tell me about the last time you checked attendance.” “What information did you need?” “Where did you get stuck?” Ask permission before taking notes or recording. Follow your organisation’s research and information-handling arrangements.

Include people whose circumstances or support needs differ. Do not assume one confident system user represents everyone. Ask participants to describe a recent task instead of only asking whether they like a proposed feature.

4. Write the need in plain language

Example: “As a training administrator, I need to identify attendance records that are incomplete, so that I can follow up before preparing the weekly report.”

Attach the evidence that supports the statement. Record who the need applies to, when it occurs and which questions remain unresolved. Keep the dashboard request alongside it as a possible response.

5. Consider more than one response

The fictional team might investigate a clearer input form, an exception list or a revised handover process. Compare these against the observed problem. Avoid selecting the most elaborate option simply because it looks impressive.

6. Agree how to check improvement

Define what you would observe if the need were better met. For this example, the administrator should be able to identify incomplete records and take the required follow-up action. Establish the current baseline before attaching a numerical target.

Try it now

Choose one request in your workplace or study project. Produce a one-page note containing the request, evidence, assumptions, user need, possible responses and next research question. Ask a colleague to identify any unsupported conclusions.

This exercise supports discovery. It does not replace a complete requirements, accessibility or service-design process.

Cover image: AI-generated illustrative scene.