3 Defining User Needs and Problems

Move from evidence to patterns

Research may produce interview notes, observations, survey results, service records, and other evidence. The goal of making sense of this material is to understand who is experiencing a problem, what they are trying to accomplish, and why the difficulty occurs—not to jump immediately to a product idea.

A practical process is to collect evidence while distinguishing what participants said or did from interpretations. Include relevant context, such as the task, environment, and constraints. Then group related observations by recurring behaviors, barriers, goals, or circumstances. Patterns may recur across several people or emerge from a particularly revealing case, but they should be checked against the evidence.

Develop and check insights

Synthesis turns organized research material into an understanding of patterns that matter for design. Interpret a pattern by asking what may be causing it and what it reveals about the user’s underlying goal. An insight is a concise interpretation that explains a meaningful pattern and can guide design decisions.

For example, research may show that people repeatedly abandon an online application when asked for information they do not have nearby. The observation is that applicants leave the form at that point. A possible insight is that they need to know what to prepare before starting, rather than encountering document requirements partway through the task. This interpretation explains a barrier without assuming a particular interface or feature.

Keep three levels distinct:

• Observation: What a person said or did.

• Insight: What a repeated or significant observation suggests about a person’s goals, behavior, or context.

• Design idea: A possible response to an insight.

After developing an insight, trace it back to research evidence, note uncertainty or exceptions, and share it with the team so others can question or refine the interpretation. Keeping observations, insights, and design ideas separate helps prevent assumptions from being mistaken for research findings.

Describe needs as outcomes

A user need describes what a person must be able to accomplish and why it matters. Express the need as an outcome rather than a feature or channel. For example, “I need to know which documents to prepare so I can complete the application in one sitting” describes an outcome. “I need a checklist” already proposes a solution.

A useful format is:

[User or group] needs to [accomplish an outcome] because [reason or insight].

Ground needs in research and use language users can understand. Make them specific enough to guide design without dictating how the need must be met. Include relevant differences in users’ circumstances rather than assuming one person represents everyone.

Focus the challenge

A problem statement focuses the team on a user and a meaningful challenge. One common structure is:

[User] needs a way to [need] because [insight].

For example:

First-time applicants need a way to understand which documents to prepare before beginning because discovering missing information partway through the form can interrupt completion.

This statement identifies a user, an outcome, and a reason. It does not prescribe a checklist, reminder, or redesign. A strong statement is evidence-based, understandable, and focused enough to guide work while still allowing different solutions.

Frame open design opportunities

A design opportunity reframes a problem to invite exploration. One useful format is a “How might we…?” question:

How might we help first-time applicants prepare the information they need before starting?

Keep the question open enough to allow several approaches but bounded enough to stay connected to the research. If it names a specific feature, broaden it; if it could apply to almost any situation, make its user or context more specific.

Teams can generate several opportunity questions from one insight, compare which are most important to users, and investigate unresolved assumptions before committing to a direction. Research, design, and technical or operational perspectives can help test whether the framing is grounded in user evidence and workable in its real-world context. The chosen framing remains provisional: prototypes and further research may reveal that the need or problem should be revised.