Understanding User Needs, Pain Points and Opportunity Areas

A user need is what someone is trying to achieve and why, expressed in their own language rather than a feature list. The GOV.UK Service Manual recommends writing needs as ‘I need/want/expect to… so that…’, which forces the focus onto the outcome a person wants rather than a solution already in mind (Government Digital Service, 2016). Christensen et al. (2016) make a similar point through the ‘Jobs to Be Done’ theory: people do not buy products or use services for their own sake; they ‘hire’ them to make progress on a specific job, and that job has functional, social and emotional dimensions. A parent chasing a school application is not just filing a form; they are trying to secure their child’s future, and the service should be judged against that job, not just the form’s usability.

Pain points are the moments where the current experience gets in the way of that job. Gibbons (2021) sets out three levels worth separating:

• Interaction-level pain points are usability problems within a single touchpoint, such as a confusing form;
• Journey-level pain points span multiple touchpoints, such as inconsistent information between phone and online channels;
• Relationship-level pain points build up over repeated contact with an organisation, eroding trust over time, a distinction Nielsen Norman Group (2022) also illustrates well.

Treating every complaint as the same kind of problem leads to fixes that patch a screen while the underlying journey, or the relationship, stays broken. Frequency and severity both matter when deciding which pain points to act on first: a rare but severe failure can deserve more attention than a common minor irritation.

These findings only surface through real contact with users, not internal opinion. Interviews, contextual observation, diary studies and journey mapping each reveal different layers of a need or pain point, and the GOV.UK Service Manual is clear that any suggestion not grounded in research should be treated as an assumption still to be tested, however senior or confident the person raising it (Government Digital Service, 2016). Research should continue through every phase of a service’s development, not stop once a first set of needs has been documented.

Opportunity areas sit between the two. They are not the need itself, and not simply the pain point restated, but a reframed space for action that points towards a better outcome. A useful discipline for reframing is the ‘How might we’ question, which turns a research insight into an open, solution-neutral prompt for ideation rather than jumping straight to a fix (IDEO U, 2025). Stickdorn et al. (2018) describe this as moving from divergent research, where the goal is to understand the full picture, to convergent synthesis, where patterns across many small observations are pulled into a shared understanding the whole team can design against.

The Design Council’s Double Diamond frames this as the shift from Discover to Define: discovery is about gathering evidence widely through interviews, observation and analytics, while the define stage is about making sense of it, choosing which needs and pain points matter most, and stating the challenge in a way that is specific enough to design against (Design Council, nd). Skipping straight from discovery to solutions, without this synthesis step, is one of the most common reasons teams design something that is well made but solves the wrong problem.

In practice, needs, pain points and opportunity areas should each be traceable back to evidence, not assumption. A note from a single interview is an observation; a pattern that shows up across multiple people, sources or research methods is closer to an insight worth acting on. Leaders reviewing research findings should ask what evidence sits behind each need or pain point, how many people it affects, and how it was observed, before agreeing it is worth designing around.