Empathy is one of those words that gets said a lot in design conversations and examined rarely. It appears in process documents, in job postings, in mission statements. It is treated as a trait that good designers have rather than a practice that all designers can develop.

That distinction matters. Empathy as a trait is either present or absent, a fixed quality you either bring to the work or do not. Empathy as a practice is something you build through specific habits, through methods that force you outside your own assumptions and into sustained contact with people whose experience differs from yours.

The limits of imagining your user

Most design work begins with some version of a user persona: a name, a job title, a list of goals and frustrations assembled from a mix of research, assumption, and reasonable inference. Personas are useful tools for keeping conversations grounded, but they have a failure mode that is easy to miss.

When a persona is detailed enough to feel real, teams sometimes stop checking whether it is accurate. The imagined user starts to crowd out the actual user. Decisions get validated against the persona rather than against real people, and the distance between the product and its users quietly grows.

The antidote is not to stop using personas. It is to keep returning to the source. Regular contact with actual users, not as a phase in a process but as an ongoing habit, keeps the mental model honest.

What listening actually looks like

Listening in a design context is not asking people what they want. That question tends to produce answers shaped by what people think is possible, what they think you want to hear, or what they want to want rather than what they actually need.

More useful is watching people work and asking them to narrate what they are thinking. Asking about past experiences rather than hypothetical preferences. Asking what they do when the product fails them, because the workarounds people invent are often the clearest signal about where the design falls short.

The goal is not to collect feature requests. It is to understand the underlying problem well enough that you can solve it in ways the user would not have thought to ask for.

Empathy at scale

One practical challenge is that deep empathic work does not scale easily. You cannot sit beside every user. Research takes time and resources that are not always available. Teams working at pace often end up treating empathy as a project phase rather than an ongoing practice, something that happens during discovery and then gets suspended when building begins.

The better approach is to find ways to keep user reality present throughout the work. Short, frequent sessions rather than long, infrequent ones. Sharing research broadly so that engineers and writers and product managers encounter user perspectives directly, not filtered through a summary. Building feedback loops into the product itself so that signals from real users arrive continuously.

None of this replaces deep research. But it keeps the team from drifting too far from the people they are building for.