2 User Research and Needs Analysis

Start with users and their needs

User research helps a team understand who uses a service, what those people are trying to achieve, and what gets in the way. Needs analysis turns evidence from research into clear user needs and actionable requirements. Investigate the problem before committing to a solution so that research does not simply validate a predetermined design.

Plan around decisions and questions

Begin with a decision the team needs to make. Write research questions that will inform that decision and identify the assumptions that need testing. For example, “Why do applicants abandon the form?” investigates behavior and causes, while “Would users like a shorter form?” presumes a particular solution.

A practical research plan records:

• Objectives and questions: What the team must learn and what it will do with the answer.

• Users and context: Which current or likely users should take part, including people who face barriers; consider staff or others who support users when relevant.

• Methods and activities: What evidence will answer the questions.

• Recruitment and access: How participants will be found and what accommodations or support they may need.

• Logistics and ethics: Where sessions will happen, who will take notes, what will be recorded, and how consent and personal data will be handled.

• Analysis and sharing: When the team will review findings and how those findings will inform decisions.

Choose a focused set of questions for each research round. Let the plan adapt as evidence accumulates rather than trying to answer every question at once. Include a range of relevant users; one “typical” participant should not be treated as representative of everyone.

Match methods to what you need to learn

Choose methods according to what the team needs to learn, not simply what is easiest to arrange. Methods often complement one another.

• In-depth interview: Explore what users are trying to accomplish and why. Interviews can reveal goals, circumstances, motivations, and reported difficulties.

• Contextual observation or contextual interview: Learn what people actually do in their normal setting, including workarounds, tools, interruptions, environmental constraints, and behavior in context.

• Moderated usability test: Investigate how people complete a particular task using an interface, including where they hesitate, misunderstand, or fail.

• Survey or existing quantitative data: Assess how common a known behavior or preference is. These methods can show patterns across a larger group and help measure prevalence, but are not usually suited to discovering detailed causes.

What people report in interviews may differ from what they do. Observation provides evidence about behavior and context; brief follow-up questions can clarify what an observer cannot infer. Surveys can estimate how widespread a known issue is, while interviews and observation are usually better for exploring unfamiliar problems.

Conduct sessions ethically and accessibly

Prepare a discussion guide that connects each topic to a research question. Use open, neutral prompts such as “Tell me about the last time you…” or “What happened next?” Ask about specific past events rather than relying only on predictions or preferences. Avoid leading prompts such as “You find this step confusing, don’t you?” When more context is needed, follow up with questions such as “What made you do that?” or “Can you show me?” Pilot the guide with a colleague and revise questions that are unclear.

At the start of a session, explain its purpose, what participation involves, how notes or recordings will be used, and that participation is voluntary. Obtain informed consent before recording or collecting personal information, and handle research data securely. Arrange accessibility support and a suitable setting; do not assume every participant can use the same equipment or communication method.

Observe behavior without confusing it with interpretation

Let an observed activity unfold as naturally as possible. Note actions, context, tools, interruptions, and obstacles. Ask occasional clarifying questions when needed, while recognizing that frequent questions can change the behavior being observed.

Separate what you directly saw or heard from your interpretation. “Reopened the instructions three times” is an observation; “did not understand the instructions” is an inference that needs investigation.

Synthesize evidence carefully

Bring observations together while the evidence is fresh. Keep each note to one specific observation and label it with its session or participant identifier. Group related observations into themes, then check those themes against the underlying notes, recordings, or examples.

Distinguish three kinds of output:

• Observations: What happened.

• Findings: A supported pattern or insight.

• Recommendations: A proposed response.

Do not turn one striking comment into a general rule without checking how well the evidence supports it.

Turn user needs into requirements

Write each user need from the user’s perspective, describing a goal or problem rather than a feature the team has already decided to build. A useful pattern is:

I need to [accomplish a goal] so that [the outcome or reason].

For example, research might show that people applying for a permit must pause to find information on a separate document. A need could be: “I need to know what information is required before I start so that I can complete the application without searching for documents halfway through.” By contrast, “Add a checklist to the first page” is a possible design response, not the need itself.

A user requirement makes the need actionable by specifying relevant conditions or capabilities without unnecessarily prescribing the interface. For the permit example, a requirement could be: “Before the application begins, users can review the required information and documents.” Requirements should be grounded in evidence and considered alongside context, user priorities, and technical or operational constraints.

Keep links between research findings, needs, requirements, and later design decisions. These links let the team revisit assumptions and verify whether the service meets the need. Translate needs into traceable, testable requirements and refine them as new evidence emerges.