Essay / Product & Entrepreneurship
Users Are Better at Describing Pain Than Designing Your Product
Use interviews to understand recent behavior, workarounds and constraints. Treat feature requests as clues to investigate before committing to a solution.
“Could you add an export button?” is useful research input, but it is not yet a product requirement. The request may mean that someone needs a report for a manager, a backup before a risky update, a way to work offline or an escape from an unreliable integration. Each explanation suggests a different design.
Users know the work they are trying to accomplish and the friction they encounter. They may also propose excellent solutions. The product team’s responsibility is to understand the underlying situation before committing to the first implementation named in a conversation.
Listen carefully to the problem. Treat the proposed solution as another hypothesis.
Begin with a recent event
A question about the last time a problem occurred usually produces more useful detail than a question about what someone might want someday. Ask what triggered the task, what they tried, which information they used and where they became stuck.
For the export request, ask to walk through the most recent occasion. What did the person need to send? To whom? What happened when they could not export it? Did they copy values manually, take screenshots or postpone the work? These details reveal the consequence of the missing capability.
The GOV.UK guidance on in-depth interviews recommends exploring people’s circumstances and experiences with open questions and follow-up prompts. The useful discipline is to make room for the participant’s account instead of steering them toward the solution already in the team’s backlog.
A recent event is still a recollection, not a perfect recording. Where appropriate and consented, ask to see the relevant artifact or workflow. A redacted spreadsheet, an empty template or a demonstration with safe data can clarify details without exposing private information unnecessarily.
Separate what happened from what is proposed
Research notes become more reliable when observations and interpretations remain distinguishable. “The participant copied five fields into a weekly report” describes reported behavior. “They need a reporting dashboard” is an interpretation. “We should add scheduled exports” is a proposed response.
Keeping those layers separate allows the team to consider alternatives. The same reported behavior might be addressed by a reusable export, a clearer detail page or a change in the downstream reporting process. The original observation should remain available even if the preferred solution changes.
Use the participant’s own language for the problem where possible, while avoiding long collections of quotes detached from context. A memorable sentence can be persuasive precisely because it is vivid. It still needs to be understood within the task and circumstances that produced it.
Do not turn one participant’s request into a universal statement about users. Record who encountered the issue, in what situation and with what consequence. That scope matters when deciding whether the problem is common, severe or specific to one unusual workflow.
Watch for questions that contain the answer
“Would a dashboard help you save time?” makes agreement easy. It suggests the feature, the benefit and the desirable response. A participant can sincerely agree without ever choosing to use the dashboard in real work.
A more useful question asks how the work is currently done and what takes effort. If a proposed concept is shown later, ask the participant to use it for a specific task and explain what they expect to happen. Observe confusion and assumptions rather than only asking whether they like it.
Questions about future willingness also need caution. Saying that a feature sounds useful is different from rearranging a workflow, supplying data or paying for a product. Those behaviors have costs that a hypothetical conversation may not make salient.
This does not make stated preferences worthless. Preferences can reveal language, priorities and concerns. They should be treated as one kind of evidence, with limits, rather than as a substitute for observing what happens when the person faces a real choice.
Workarounds reveal the missing contract
A workaround often contains information that a feature request omits. A spreadsheet may exist because users need to annotate exceptions. A screenshot may preserve the state of a record at a particular moment. A copied email may serve as evidence of approval.
If the new product removes the workaround without preserving its purpose, it can make the workflow worse despite reducing manual steps. The team might automate data transfer while losing the annotation or approval trail that made the process trustworthy.
Ask what each artifact does for the person. Which fields are manually added? Which values are checked against another source? Who receives the result? What happens when two sources disagree? These questions expose the agreements surrounding the task.
A workaround is often a small system whose requirements were never written down.
That observation connects research to engineering. Understanding the workaround helps define the data model, permissions and recovery behavior of the eventual solution. It also reveals where a product should integrate with an existing process rather than attempt to replace it wholesale.
Respect expertise without outsourcing design
Participants may understand domain constraints far better than the product team. Their proposed solution can encode years of practical knowledge. Investigating the underlying problem should not become an excuse to dismiss their judgment.
At the same time, designing a product requires considering other users, technical constraints, accessibility, operational cost and interactions across the system. A request that is locally sensible may conflict with another legitimate need. The team remains responsible for resolving that trade.
A productive response is to explain the problem as understood and test whether that interpretation is accurate. Then explore possible solutions with the participant, including their proposal. This treats them as a knowledgeable collaborator without pretending that a single interview can settle the whole design.
Be especially careful when a request comes from a powerful stakeholder. Organizational authority can make one preference appear representative. Separate the stakeholder’s decision rights from the evidence about the people who will perform the task.
Synthesize patterns without erasing differences
Research synthesis should identify recurring problems while preserving meaningful variation. Two people may ask for exports for entirely different reasons. Conversely, several different feature requests may point to the same missing ability to inspect and explain changes.
Group observations by task, trigger, consequence and constraint before grouping them by requested feature. This makes it easier to see whether one intervention could address several problems or whether apparently similar requests need distinct responses.
Look for contradictory evidence. A workflow that helps an occasional user may slow down an expert. A default that works for one supplier may be wrong for another. These differences are design inputs, not inconvenient notes to remove from the presentation.
The validation essay explores why supportive feedback alone is insufficient. A synthesis should help the team make a decision, including identifying what remains uncertain and which observation would most usefully challenge the emerging interpretation.
Return to the task with a concrete proposal
After research, test a proposed solution against the original situation. If the problem was preserving a reviewable snapshot, does the design actually preserve it? If the problem was sending data to another system, is the output compatible with that system’s contract?
Use a task rather than a tour of features. Ask the participant to complete the relevant work and observe where the design supports or interrupts it. A prototype can be enough if it faithfully represents the decisions being tested; missing behavior should be explained honestly.
Record whether the solution addresses the consequence, not merely whether the participant recognizes the requested feature. An export button that produces an unusable file satisfies the literal request while leaving the job unfinished.
The strongest research outcome is a clear connection between observed work and a design decision. The team can explain whose problem it addresses, why the proposed response fits and what evidence still needs to be gathered. That is more durable than a backlog filled with requests whose original purpose has been forgotten.