Customer needs: understand the problem before choosing a solution

Understanding customer needs means explaining what people are trying to achieve, in which circumstances, and what prevents them from doing it. A useful need statement leaves room for several responses. “I need to know whether my bicycle is ready before arranging the journey home” is a different starting point from “build a repair-status app”.

Customer requests matter, but they are only one kind of evidence. Observed behaviour, a person’s account of their reasons and the surrounding service conditions can support different interpretations. Your task is to connect them carefully enough to define a problem worth addressing.

This is the work between discovering a difficulty and committing to a concept. The Double Diamond gives that transition a place; this guide explains what to put into it. The continuous example is a hypothetical bicycle repair shop, not a reported business case.

Keep a request, a behaviour and a need separate

Imagine that a customer asks the repair shop for an app. Write down the request as given. It may reveal a familiar solution, a frustrating experience or a preference about communication. It does not establish that the app is the best response.

Next, distinguish what the team actually knows. A researcher sees the customer looking at a bus timetable before asking when the bicycle will be ready. During a conversation, the customer explains that they need to arrange collection around a limited bus service. The timetable check is observed behaviour; the explanation is a reported reason; the need statement is the researcher’s synthesis of both.

GOV.UK’s guidance on user needs recommends evidence-based statements focused on a person’s problem rather than a specific solution. Its government-service context differs from a commercial workshop, but the distinction helps keep the shop’s investigation open.

A request should remain attached to the evidence trail even if the team reframes it. Otherwise researchers can replace the customer’s words with their own preferred abstraction and call that listening. Record the original wording, situation and interpretation together.

Start with one recent situation

Ask about a concrete experience before asking for general preferences. When was the bicycle last unavailable? What did the customer need to do that day? Who else depended on the journey? What information was available, and what happened after they acted on it?

Use customer interviews to reconstruct the sequence without suggesting an app, reminder or collection service. If the customer describes repeated trouble, ask for a particular instance. An honest gap in recall is more useful than a confident answer produced through persistent prompting.

In the hypothetical shop, a commuting customer may need the bicycle for an early shift. Someone repairing a weekend bicycle may have more flexibility. A parent collecting a child’s bicycle might need to coordinate with another person. The physical repair can be identical while the surrounding difficulty differs.

Make those differences visible in the notes. “Customers value convenience” does not help the shop decide what information to provide or when. “People arranging a shared car journey need a dependable collection window before the driver leaves” gives the investigation a useful boundary.

Avoid treating the visible customer as the entire service system. Map the people who support the task: mechanics, reception staff and whoever authorises an additional repair can all explain constraints that the customer cannot see.

Look at the environment as well as the account

People do not always describe the details that make a task difficult. A collection slip might use a date without specifying whether it is a promise or an estimate. A repair may await the customer’s approval. The shop may close before a customer finishes work. These conditions deserve investigation alongside attitudes.

GOV.UK’s contextual research guidance describes observing activities in everyday surroundings and checking unclear events through questions. Use a planned observation when seeing the task would answer something that a retrospective account leaves uncertain.

For the repair shop, this could mean following an agreed handover from intake to collection, with participants’ understanding of the research. Notice which information gets recorded, where someone checks progress and how a change reaches the customer. Do not turn a normal research visit into a covert assessment of individual employees.

A journey map can organise the sequence after evidence exists. Mark unsupported cells as questions. A smooth-looking map cannot supply the missing account of people who abandoned the service or collected through a family member.

Treat motives as interpretations to examine

A motive is an explanation of why something matters to a person. It is easy to overreach: a customer who checks twice might be protecting a tight schedule, handling someone else’s bicycle or seeking reassurance after a previous delay. “They are anxious” is not established by the repeated check.

Jonathan Gutman’s 1982 means–end paper presents a conceptual model linking perceived product attributes to values. That provides a useful reason to ask what an attribute enables. It does not give researchers direct access to somebody’s underlying psychology.

Stay close to the task. Ask what would become easier if the information were available earlier, and what happens when it is missing. Invite correction of your account. You do not need to force every practical preference into a hierarchy of universal human needs.

The COM-B framework distinguishes capability, opportunity and motivation in understanding behaviour. In this setting it offers a caution against explaining everything through desire: a customer may want to collect promptly but lack transport or a workable opening time. Our use is an interpretive aid, not a diagnosis established by that paper.

Make an evidence record another person can question

Keep each candidate need connected to its support and its uncertainty. The following original worksheet is filled with invented material to illustrate the distinction. It is not a validated assessment.

Evidence item	Candidate interpretation	What still needs checking
Customer reports calling before borrowing a car	Readiness information affects transport arrangements	Whether the same issue appears with other collection routes
Researcher sees a customer checking a timetable	Collection timing may constrain the onward journey	What information the customer was looking for
Reception describes different meanings of “ready”	The service promise may be ambiguous	Whether actual messages differ and how customers interpret them
Customer asks for an app	Digital status may be an acceptable response	Whether it solves the timing problem and excludes anyone

GOV.UK’s analysis guidance separates observations, findings and actions. Preserve those distinctions even when summarising for a sponsor. “The app will reduce anxiety” bundles a solution and an outcome that this evidence has not established.

Look deliberately for contrary cases. A customer who arranged collection without difficulty may have received a clear telephone confirmation, lived nearby or used a different repair type. Understanding the difference may narrow the need more productively than adding another confirming quotation.

Turn evidence into a bounded problem statement

Write a statement containing the affected group, situation, difficulty and consequence. Add its supporting records and the conditions outside its present scope. The wording should be specific enough to guide a decision and open enough to admit different responses.

For the hypothetical shop: “Customers who must arrange transport cannot reliably distinguish an estimated completion date from a confirmed collection time, so they may make arrangements before the repair is ready.” That is a candidate problem statement, subject to the evidence gathered. It does not claim every customer encounters the problem.

Design Council’s explanation of the Double Diamond places understanding the problem before defining the challenge and developing responses. Its framework supports this separation; it does not certify that a team’s particular statement is correct.

The shop now has several options: clearer estimate wording, a confirmed telephone callback, a message when approval is required or a different collection arrangement. An app is one possibility. The next decision is which uncertainty to investigate, not which feature to announce.

Give the statement to someone who was not in the sessions. Ask what they believe it means, who it concerns and which evidence they would expect. If they hear “all customers need notifications”, revise the statement or the supporting explanation.

Prioritise the difficulty before ranking features

Consider consequence, occurrence within the evidence, accessibility, strategic fit and the organisation’s ability to act. Keep these judgements separate. A frequent minor irritation and an uncommon disruption to an essential journey may deserve different responses.

Small qualitative rounds can reveal a consequential problem without estimating its population frequency. If the decision requires that estimate, write a research design that addresses it. Do not convert a handful of interviews into a percentage of the market.

Use assumption mapping when the team is tempted to collapse uncertainty into confidence. The shop may understand the customer’s coordination difficulty while still being uncertain whether staff can produce a dependable readiness confirmation. Customer relevance and operational feasibility need different evidence.

Later, the Kano model can examine how people respond to the presence or absence of a specified requirement. It does not replace discovering the task or settle the importance of an internally invented feature. First establish a credible requirement; then decide whether that form of classification is useful.

Carry the need into concept development

A need statement is useful only if it shapes the next work. Put it into a concept brief beside the promised benefit, delivery arrangement and key assumptions. Keep the original evidence reference available as the concept changes.

For the shop, a short rehearsal might examine whether reception and mechanics can agree on what counts as confirmed readiness. A separate customer activity could examine whether the wording supports collection planning. These are different investigations, and neither proves ongoing customer demand.

Name an owner and a review date for each open question. Review the need when research includes a new group, the operating process changes or a proposed response introduces a new burden. For example, a notification that requires downloading an account-based app could create an access problem that the original need statement never addressed.

Evidence and limits

Needs are contextual interpretations supported by evidence, not hidden facts extracted from a persuasive quotation. Customers can misremember events; researchers can select a convenient story; records can exclude unsuccessful attempts. Different sources may disagree because they describe different circumstances rather than because one is necessarily wrong.

The cited sources provide research concepts and professional guidance. They do not establish that this worksheet predicts sales, loyalty or implementation success. The repair-shop narrative and decisions are hypothetical.

Finish discovery with a statement you can challenge: whose situation you understand, what difficulty is supported, which alternative explanations remain and what evidence the next decision needs. That makes the customer need an accountable starting point for design. It also keeps a reasonable request from becoming a premature product commitment.