Find the Cause Behind Customer Pain Points
Imagine a customer who asks for a reminder before an application deadline. A reminder sounds like a clear request, and adding one sounds like a clear improvement. Yet the customer may have missed the deadline because the date was hidden in a confirmation message, because the application required a document they could not get in time, or because they did not know the application was unfinished. Each situation calls for a different response. The request is useful, but it does not yet tell the team what made the task difficult.
That distinction is the heart of a customer pain point. A pain point is a specific obstacle, uncertainty, or unwanted cost a person encounters while trying to accomplish something. The useful unit is not a complaint in isolation. It is the person, the task, the moment the difficulty appears, and what happens as a result. A team that can describe those four things can choose a change that has a chance of helping. A team that merely collects complaints may build the most frequently requested feature while leaving the actual obstacle in place.
This article uses service journeys to make that judgment concrete. The same reasoning applies when the task is buying a product, setting up an account, requesting support, or renewing a service. The examples below are illustrations, not reports of observed customers. The practical aim is to turn a loose phrase such as “the process is confusing” into a decision about what to change, whom the change should help, and what the team still needs to learn.
A pain point starts with a task, not a feature request
People come to a service to get something done. The GOV.UK Service Manual defines a user need by the outcome the person must be able to achieve through the service, and advises teams to understand the person’s current task, frustrations, and circumstances before designing a response. It also separates the underlying need from a suggested solution: someone may need a reminder without needing that reminder to arrive as an email or letter. GOV.UK guidance on user needs gives that distinction a practical form.
Suppose, illustratively, that a person is renewing a permit. The task is to complete the renewal before the old permit expires. The pain point might be that the person cannot tell which documents are required until late in the process. “Add a checklist” is one possible solution; it is not the problem itself. The obstacle could instead be that the document rules change depending on the applicant’s circumstances, or that the documents are known but take longer to obtain than the person has. A checklist could solve the first version and do little for the other two.
A useful description therefore keeps the action and the consequence together: when an applicant reaches the document step, the requirement for a particular document is unclear, so the applicant stops or submits the wrong material. That sentence gives a designer something to inspect and gives a service owner a reason to care. “The form is bad” does neither. It also avoids claiming that all applicants experience the problem, which a few conversations could not establish.
Not every unpleasant moment is equally important. A field label that takes a second reading may be irritating; a requirement that prevents completion may block the task entirely. A delay may be tolerable when the person is exploring options and costly when a deadline is close. The meaning of the obstacle comes from what the person was trying to do and the conditions around it. The GOV.UK guidance explicitly asks teams to consider what triggers a need and what circumstances constrain the person. Its format for writing user needs is a useful check against a pain-point statement that floats free of context.
This is also why a pain point should not be defined solely by a screen or department. The person trying to renew the permit may struggle before opening the form, while gathering records, or after submitting it, while waiting to learn whether the renewal is complete. A team responsible for the form can still describe an obstacle outside its immediate control. Otherwise, it risks improving the part it owns while the person’s task remains hard.
Similar complaints can point to different causes
“Too slow” is a good example of a complaint that needs interpretation. One person may mean the pages take too long to load. Another may mean the form asks for information they have already supplied. A third may finish the form quickly but wait for a decision without knowing its status. Calling all three “speed pain points” creates an attractive theme and a poor plan. The first invites a technical change, the second a change to the questions or data flow, and the third a clearer account of what happens after submission.
The same ambiguity appears in requests. In the opening illustration, a reminder could be the right choice if people understand the deadline but forget it amid other obligations. It is a weak choice if the date is unclear, or if customers need an earlier warning about documents that take time to obtain. Before selecting the delivery channel, establish what the person was attempting, what they expected at that moment, what they saw, and what they did next. A feature request is a clue to investigate, not a specification to accept on sight. The GOV.UK user-needs guidance makes the same distinction between a person’s problem and a possible solution.
There is a second trap: assigning one cause to every occurrence of the same word. Two customers may both call a payment step “confusing.” One cannot tell whether payment has been taken; the other cannot tell which fee applies. The first needs a clearer transaction state, and the second needs a clearer rule before payment. If notes preserve only the adjective, the later decision will be made on missing information. GOV.UK’s guidance for analysing research sessions recommends recording what people actually said or did before grouping observations and drawing conclusions. That sequence protects the circumstances that make a complaint intelligible.
The practical test is to ask whether the proposed pain-point statement predicts a useful change. “Customers dislike payment” predicts almost nothing. “Applicants cannot tell whether the payment went through after the confirmation page fails to appear” points toward a specific moment and a specific uncertainty. It may still be wrong, but the team can inspect that moment and ask better questions. A pain point becomes decision-ready when it identifies a difficulty precisely enough that competing explanations can be checked.
Follow the journey far enough to find the obstacle
The first place a customer complains is not necessarily where the difficulty began. Consider a purely illustrative account setup. A customer contacts support because a verification code has expired. The visible problem is the expired code. The earlier difficulty may be that the customer had to leave the account setup to find an identity document, then returned after the code’s validity period. Shortening the support response would help with recovery, but a clear document requirement before the code is sent might prevent the interruption.
Trace the customer’s route from the trigger to the outcome. What made them start now? What information did they already have? Which channel did they enter through? What did they need to gather, decide, or wait for? At what point did progress stop, and what did the person do instead? In a service journey, the alternate action matters: retrying a page, calling for help, abandoning the task, or submitting uncertain information each creates a different cost. GOV.UK recommends learning how people currently complete a task, including the services or channels they use, and where they encounter problems. Its guidance on learning about users supports looking beyond the interface where the complaint surfaced.
Context should stay attached to the observation. “Could not upload a photo” leaves out the condition that would guide a fix. Did the person lack a suitable photo? Did the instructions omit the required format? Did the upload control fail on the device in use? Did a rejection appear only after the person thought the task was finished? These are distinct possibilities, not claims about any real service. The GOV.UK session-analysis guide uses photo requirements, taking a photo, and reasons for rejection as examples of smaller themes that can sit inside a broad “photos” group. A label useful for sorting notes is not yet specific enough for a product decision.
One compact way to preserve the context is to write the observation in four parts: when the person was trying to do the task; what they attempted or encountered; where progress became difficult; and what followed. In the illustrative account setup, that could read: “When returning to setup after collecting an identity document, the customer found the verification code had expired and had to restart.” The sentence does not pretend to know why the code expired or how common the incident is. It gives the team a place to inspect and a reason to ask whether the document step should come earlier.
The form of this note matters because a customer journey can be long. Without the task and consequence, teams tend to collect isolated moments and improve whichever one is easiest to reach. With them, the team can see whether a change at the start, in the middle, or during recovery would remove more work for the customer. The most useful pain-point statement is often the one that makes the next design choice narrower.
Talk to people who can reveal the missing part
Once a likely obstacle is described, decide whose experience would change the decision. A team trying to understand first-time setup should not rely only on people who have used the service for years. A team concerned about unsuccessful applications needs to hear from people who stopped, sought help, or were rejected, as well as those who completed the process. This is a recruitment choice, not a claim that one group speaks for all customers. GOV.UK’s service research planning guidance starts with the questions the team needs to answer and the user groups relevant to those questions.
The question determines the method. If the issue is unclear wording, watching someone try to complete the task can expose where their interpretation changes. If the issue is why they began the task or what they did before reaching the service, a conversation about the surrounding circumstances can be more useful. Existing search terms, support contacts, or previous research can suggest where to look, but they do not by themselves explain what a particular person meant. The GOV.UK guide to learning about users names existing records, interviews, observation, and people who support users as ways to learn; the right combination depends on the question at hand.
Recruitment also changes what can be seen. If every participant uses a recent device, the team may miss trouble that appears on older equipment. If everyone has the required documents at hand, a document-gathering obstacle may stay invisible. If the service is intended for people who may need support, their circumstances must be included when the team wants to understand that part of the journey. GOV.UK asks teams to consider different user groups and, for broad audiences, include disabled users and people who may need support in research planning. The planning guidance frames inclusion as part of understanding the service, not as a footnote added after conclusions have been drawn.
Do not treat a small round as a miniature market survey. Its strength is seeing where a task breaks and hearing why, in the circumstances of the people included. Its weakness is estimating how often the issue occurs across everyone who could use the service. A person excluded by the recruitment criteria cannot appear in the results, however carefully the included sessions are run. The sensible response is to state who was included, follow up with groups that could change the answer, and avoid a population claim the work was not designed to support.
Separate what happened from what you think it means
After a conversation or observation, there is a strong urge to jump to a solution. A customer pauses at a form field; someone writes “the wording is confusing.” Perhaps it is. The customer may also be checking a document, deciding whether a question applies, or recovering from an interruption. Recording the pause, the field, the person’s words, and the next action leaves room to find out. Recording only the interpretation makes the next round of work inherit an untested assumption.
The GOV.UK guide to analysing a research session separates observations, grouped themes, findings, and actions. That distinction is useful even when the team has a modest number of notes. An observation says what happened. A finding explains a pattern the team can defend from those observations. An action is a proposed response. Keeping those three statements separate lets a colleague challenge the explanation without erasing the customer’s experience.
For example, in an illustrative permit-renewal exercise, an observation might say that a participant opened the document help page, returned to the form, and left the task before uploading anything. A possible finding is that the document instructions did not answer the participant’s question. A proposed action is to rewrite the instructions. Yet the observation alone cannot establish the finding. The participant might have left to retrieve the document, or the help page might have clarified that they were ineligible. A follow-up question or a closer look at the task is needed before the team commits to a rewrite.
Grouping notes is helpful when the grouping preserves those differences. Notes about unclear document names, missing documents, and rejected uploads may all belong in a broad document area; they should not be merged into one “upload problem.” Conversely, two complaints on different pages may share one cause, such as inconsistent names for the same document. The team should be willing to move a note when the explanation changes. GOV.UK describes sorting observations into themes and then reviewing each group to determine what the observations mean. The session-analysis guidance treats the groups as a way to find patterns, not as the final answer.
The most productive conclusion from a round is sometimes a question. If people hesitate at payment, the team may still need to learn whether they distrust the fee, do not understand the total, or are unsure a payment is required. Writing “payment friction” on a board can help locate the work, but it cannot choose the change. Naming the unresolved explanation prevents a vague theme from hardening into a costly feature request.
Repetition matters, but the denominator matters too
Repeated reports deserve attention, especially when the same obstacle appears at the same step under similar conditions. They do not automatically tell the team how common the obstacle is across all customers. Imagine an illustrative round with six people recruited because they recently failed to renew a permit. If four describe trouble finding the document rules, “four of six participants in this round” is a clear statement. “Most customers cannot find the document rules” is not. The recruitment deliberately concentrated on people who had difficulty, so the two statements answer different questions.
The reverse problem is also possible. If no one in a round uses a screen reader, that round cannot show whether a screen-reader user can complete the same step. If all participants have already renewed once, the round may understate confusion faced by a first-time applicant. The GOV.UK guide to planning a research round says each round should have clear objectives and a deliberate participant mix. Read the findings against that purpose and mix rather than converting the count into a market rate.
Frequency is only one reason to act. A rare obstacle that prevents a person from completing an essential task may deserve more attention than a common annoyance with an easy workaround. Conversely, a dramatic story from one participant may reflect a special circumstance that the service cannot generalize from. The decision should include the consequence, the affected step, who has been observed, and how much remains unknown. If the team needs an estimate of prevalence, it needs a way to count the relevant population with an appropriate denominator; a small, targeted research round is suited to explaining a problem, not sizing a whole market.
Precise language keeps the door open to better decisions. Say “three participants in the current round stopped at the eligibility question” if that is what was observed. Say “we do not know how often this happens among all applicants” if that is true. Neither sentence weakens the finding. It tells the decision maker what kind of weight to place on it and what further information would alter the priority.
Choose the change that removes the obstacle
The strongest response to a pain point is not always a new feature. If customers cannot find the document rule, changing the wording and placement of the rule may be more direct than sending an additional message later. If the rule is visible but depends on circumstances that customers cannot readily identify, a short guided question may help. If the requirement itself forces repeated work, better wording alone will have limited effect. The choice follows the observed mechanism, and the cost of each choice should remain visible.
Return to the opening reminder illustration. If the deadline is clear and customers simply need a prompt at the right time, a reminder is plausible. It creates a delivery obligation, however: the team must have a reliable way to reach the person and keep the timing and content accurate. If the date is buried in a confirmation message, making it visible at the point of application and in the receipt is a more direct first change. If the person cannot meet the date because a required document arrives too late, neither a prompt nor a clearer date solves the underlying delay. The team needs to understand the document path or the deadline rule before promising a fix.
A workable decision can be made without an elaborate scoring system. First identify whether the obstacle blocks completion or merely adds effort. Then ask whether it affects a group whose circumstances the current design overlooks. Next ask how confident the team is about the cause and whether a proposed change can be tried without creating a new problem elsewhere. Finally, compare the cost of the change with the cost the obstacle imposes on the person and the service. This is judgment, not arithmetic: uncertain but severe obstacles may call for another focused round of learning before a large build.
Avoid choosing a fix because it is easy to assign to a team. A support script may help customers recover from a confusing rule, but it leaves customers who never contact support with the same confusion. A form change may reduce requests for help but fail if the obstacle lies in a letter sent before the form begins. The owner of the page, channel, or department is an implementation detail. The customer experiences the whole path. GOV.UK’s user-needs guidance calls for looking at how people currently do the task, including other services and channels; that wider view is essential when choosing where to intervene.
There will be trade-offs. More guidance on a page may make a complex rule clearer for some people and make a simple task harder to scan for others. A guided question may reduce uncertainty and add a step. A reminder may prevent missed deadlines and create another message to maintain. State the trade-off alongside the proposed benefit, then test the choice with the people and circumstances that made the pain point important. A solution that looks obvious in a meeting still has to help someone finish the task.
Check whether the person can finish the task
Once a change is ready to try, the useful question is whether it changes the customer’s route through the task. For the illustrative document rule, show a revised version to people who need to determine which document to provide. Watch whether they can make that decision, where they hesitate, and whether they still need to leave the service for help. Ask about the outcome, not just whether they like the wording. A clearer page is valuable because it helps the person act correctly, not because it earns a positive reaction in isolation.
Keep the test tied to the original circumstances. If the difficulty arose on a phone while the customer was away from their records, a test on a large screen with every document already available can miss the problem. If the obstacle appeared after submission, testing only the form before submission cannot establish that the new confirmation works. The GOV.UK guidance on planning a research round asks teams to set actionable objectives, prepare the working service or prototype, and plan the people and conditions needed for the session. Those choices determine whether the test can answer the decision at hand.
There is no guarantee that a single change settles the matter. A clearer document rule may expose a second issue: the document is still difficult to obtain. A status page may reveal that customers understand the delay but cannot plan around it. Research after a change can reveal the next obstacle in the same journey. GOV.UK advises teams to keep learning about user needs as a service develops and to test designs with likely users. The user-needs guidance treats this as continuing work because the service and people’s circumstances can change.
The decision to stop or continue should follow the task, not the number of complaints arriving in one channel. Fewer support contacts could mean fewer customers are stuck; it could also mean they have stopped asking for help. More contacts could mean a new message now makes it easier to reach support. Look at the task outcome alongside the contact pattern. If people can identify the requirement, complete the step, and understand what happens next, the team has stronger grounds to say the obstacle has been reduced.
A useful pain-point statement leads to a useful decision
The phrase “customer pain points” can invite a catalogue of frustrations: long waits, confusing forms, expensive options, poor support. A catalogue can start a conversation, but it cannot tell a team which change to make. The useful statement stays close to a particular task and says where progress breaks, for whom, under what circumstances, and with what consequence. It also keeps a feature suggestion separate from the difficulty that prompted it.
For the illustrative permit example, “customers want a checklist” is a request. “Some applicants reach the document step without knowing which evidence applies to their circumstances and leave before submitting” is a testable description of an obstacle. The second statement suggests questions: Which circumstances make the rule unclear? What do people consult? What happens after they leave? It allows several possible responses, from clearer guidance to a change in the sequence of the application. It does not falsely turn one person’s experience into a rate for all applicants.
Start with the task, preserve what happened, and choose the smallest change that addresses the cause you can actually describe. When the cause is still uncertain, use the next conversation or task observation to separate the competing explanations. That discipline gives the term pain point a practical meaning: a difficulty understood well enough to guide a decision, with its limits still visible.