Empathy is not imagining harder

Empathy is one of the most agreeable words in product design.

Nobody argues for an interface that ignores people. Teams say they are user-centred. Workshops include empathy maps. Personas receive names, goals, frustrations, and photographs. Stakeholders are encouraged to put themselves in the customer’s shoes.

The intention is good.

The problem begins when imagining another person’s experience is treated as evidence of that experience.

We are not empty vessels when we imagine. We bring our own vocabulary, abilities, incentives, devices, confidence, cultural context, and familiarity with the product. A team can care deeply about users and still design around a more articulate version of itself.

Empathy is not a feeling that automatically produces the right solution.

It becomes useful through a sequence:

Listen → Locate friction → Translate → Test

The sequence turns concern into a change that another person can encounter. Without it, empathy remains a flattering story the team tells about its own intentions.

Care is the beginning, not the method

People who work on consequential products often care intensely about the audience.

At Unshackled, the mission was to help people navigate complex immigration systems. The work raised humane questions: how can this experience feel less stressful? Which information should be surfaced? How can people feel supported rather than merely processed?

Those questions matter because they direct attention towards the person living through the system.

They do not answer themselves.

One applicant may need a plain explanation of an unfamiliar term. Another may understand the term but need clarity about evidence. Someone may be reading in a second language. Someone may be helping a family member. Someone may be afraid that an exploratory action will create a formal consequence. Someone may already know the process and need a fast path past introductory material.

“Make it reassuring” is too broad to guide all these decisions.

Care supplies the motivation to investigate. The method begins when the team admits that its first interpretation may be wrong.

Listen for tasks, language, and context

Listening is more than asking people what feature they want.

People are reliable witnesses to their experience. They are not always expected to diagnose the system or design the solution. A request for a chatbot may mean information is hard to find. A request for more control may mean the current output feels unpredictable. A request for a simpler form may reveal that people do not have the required documents at the moment the product asks for them.

The listening task is to understand:

• what the person is trying to accomplish;

• what they do now;

• where they hesitate, fail, or seek help;

• which words they use for the problem;

• what else is happening around the interaction;

• what consequences make the decision feel risky.

The GOV.UK Service Manual recommends learning from existing evidence, interviewing and observing actual or likely users, and treating suggestions that do not come from users as assumptions requiring research. It also emphasises the wider context of what a person is trying to achieve, not only the moment they interact with a digital service. GOV.UK on learning user needs, its service standard on understanding users

That last distinction is easy to neglect.

A person completing an immigration form is not trying to complete a form. They may be trying to work in a country, stay with family, pursue a professional opportunity, or understand whether a path is available. The form is one institutional step inside a larger life task.

Empathy improves when the product team sees the whole task.

Locate friction precisely

“The experience is confusing” is not yet an insight.

Where does confusion begin? What does the person believe at that moment? Which cue creates the belief? What action follows? Is the problem consistent across people or specific to a context?

Precise friction might look like this:

• people expect export under the final output menu, but the action is placed elsewhere;

• a field asks for a classification before explaining the categories;

• users interpret “Continue” as saving when it submits information;

• a younger user cannot distinguish editable and generated parts of a story;

• a mobile layout places important evidence after a long decorative section;

• people repeatedly leave to find a document the service could have mentioned earlier.

The Wishtales case study illustrates the value of an outside view. As an external product and UX consultant, I could see issues such as hidden export actions, rigid content flows, limited output control, and visual complexity for a younger audience. A team close to a product can stop experiencing these as friction because it knows where everything is and why each decision was made.

An observer encounters the interface without that inherited explanation.

Contextual research is particularly useful because it shows how people use a service with their real devices, information, interruptions, and support systems. GOV.UK’s guidance recommends observing what happens and asking questions when the meaning of an action is unclear. GOV.UK on contextual research and observation

The goal is not a larger list of complaints. It is a more accurate relationship between behaviour, context, and cause.

Translate evidence into a design decision

Research does not design the product automatically.

Suppose users struggle with a long application. The response could be shorter content, fewer questions, a different sequence, saved progress, a document checklist, conditional logic, more human support, or a decision not to digitise part of the service.

Several interventions might address the same friction. Each creates different costs and consequences.

Translation makes the reasoning explicit:

Observation: People leave the flow to find a document and often do not return.

Interpretation: The service asks for evidence before people know they will need it.

Decision: Show a personalised preparation checklist before the form and allow progress to be saved.

Expected change: More people begin with the necessary material and can recover when they do not.

This chain protects the team from two common mistakes.

The first is solution theatre: a fashionable feature is presented as empathetic because it appears helpful.

The second is research theatre: observations are carefully collected, placed into a report, and disconnected from prioritisation.

GOV.UK’s research-analysis guidance recommends separating what was seen or heard from interpretation, then using the findings to inform user needs, propositions, and product roadmaps. GOV.UK on analysing research

Empathy has operational value only when it changes a decision.

Test whether the translation helped

A team can listen carefully, identify real friction, and still choose the wrong intervention.

Perhaps the checklist arrives too early. Perhaps its language remains unclear. Perhaps saved progress creates a false sense that information has been submitted. Perhaps the new control creates more options than a younger user can comfortably compare.

Testing completes the loop.

Put the changed experience in front of people who face the relevant context. Observe whether the original friction changes and whether new friction appears. Combine what people say with what they can do.

This does not always require a large study. A prototype with a small, appropriate group can reveal basic misunderstanding. Support logs can show whether the same question continues. Analytics can locate abandonment, although they rarely explain it alone. Content feedback can show which terms require definition.

The strength comes from triangulation: different evidence illuminates different parts of the problem.

Testing is also an ethical correction. It replaces “We designed this for you” with “We have a proposed response; let us see whether it helps.”

Empathy is not agreement

Understanding why someone wants a feature does not require building it exactly as requested.

Users have different and sometimes conflicting needs. A faster path for an expert can become confusing for a first-time user. More flexibility can increase cognitive burden. Greater visibility can conflict with privacy. A business must also consider viability, legality, security, maintainability, and fairness.

Empathy provides evidence for judgment. It does not eliminate judgment.

This is especially important when a user’s immediate preference may create a harmful long-term outcome. A financial product should not exploit a desire for instant access. A social product should not convert every engagement impulse into a notification. A creative tool should not treat more automated output as inherently supportive if users lose meaningful control.

The team’s responsibility is to understand the need, make the trade-off visible, and design a response that respects the person without pretending every preference can be satisfied.

Empathy is not a persona template

Personas can help a team remember patterns in real evidence.

They become dangerous when detail creates an illusion of knowledge.

A name, stock photograph, age, job title, favourite apps, and quotation may make an imagined person feel vivid. Vividness is not validity. If those details do not change a design decision or come from research, they can turn stereotypes into an artefact that looks authoritative.

Use profiles to preserve relevant differences:

• goals and tasks;

• context of use;

• experience and confidence;

• access needs;

• constraints and risks;

• behaviours supported by evidence.

Leave decorative biography out unless it matters.

The purpose is not to make the user feel real to the workshop. It is to keep the product accountable to real variation.

Run an empathy trace

Choose one feature, page, flow, or content decision currently described as user-centred.

Trace it backwards:

1. Listen: What direct or existing evidence tells us about the person’s task, language, and context?

2. Locate friction: What specifically happens, where, and under which conditions?

3. Translate: Which design or content decision did that evidence change, and what trade-off did we choose?

4. Test: What would show that the response reduced the original friction without creating a worse one?

If the trace stops at an assumption, label it as an assumption. If it ends at a research report, connect it to a decision. If the decision has never been tested, decide what level of evidence fits its consequence.

Empathy matters because products affect lives beyond the screen.

But caring about that fact is not the same as understanding it.

The work begins when we stop imagining that our concern gives us privileged access to another person’s experience—and start building the evidence, decisions, and feedback loops that allow their experience to correct our own.