A team spends three months building the feature everyone in the room was certain customers wanted. It ships. Nobody uses it. The post-mortem reveals the obvious-in-hindsight truth: no one had actually watched a customer try to do the thing the feature was meant to help with. The room had empathy for an idea of the user, not the user.

The quick version

  • Human-centred design (HCD) means designing from the needs, context and behaviour of real people, then testing your guesses against them, repeatedly, before you commit.
  • Empathy is the engine, but it's a tool, not a feeling. The point is to surface needs people can't or won't articulate, and to keep your own assumptions on the table where you can see them.
  • The international standard for HCD (ISO 9241-210) describes a four-step loop: understand the context, specify the requirements, produce solutions, evaluate against real users, and repeat.
  • The honest caveat: empathy work can flatter the designer and quietly exclude the people it claims to serve. Treat it as a discipline with guardrails, not a halo.

The idea in depth

The cleanest definition comes from the standards body, not a consultancy. ISO 9241-210, the international standard for human-centred design of interactive systems, defines HCD as an approach "that aims to make systems usable and useful by focusing on the users, their needs and requirements" and applying human-factors and usability knowledge. It frames the work as an iterative loop of four activities: understand and specify the context of use; specify the user requirements; produce design solutions; and evaluate those solutions against requirements, looping until the design is good enough (ISO 9241-210:2019).

That definition does quiet, important work. It moves "user-centred" from a vibe to a process with a test at the end of every lap. The failure mode it guards against is the one in the opening scene: a team that empathised in a meeting, decided, and never closed the loop by putting the thing in front of a real person.

So the move is: in your next planning cycle, name the evaluation step out loud before you fund the build. "Who watches a real user try this, and when?" If the answer is "after launch," you don't have a human-centred process, you have a launch with a survey bolted on.

Don Norman, who coined "user-centred design," puts the same point three ways: focus on people, find the real problem rather than the stated one, and think in systems (Norman, "Principles of Human-Centered Design," NN/g). Notice that none of those three is "have a good idea." The discipline is upstream of the idea.

flowchart LR
  A(["Understand the
context of use"]) --> B(["Specify the user
requirements"])
  B --> C(["Produce design
solutions"])
  C --> D(["Evaluate against
real users"])
  D -->|"Not good enough"| A
  D -->|"Meets the need"| E(["Ship, then keep
watching"])
The ISO 9241-210 loop: each lap ends with real users, not with a sign-off. Leaders Loop

Empathy is a tool, not a temperament

The popular version of HCD, the one most managers met through design thinking, puts empathy at the front. IDEO's Tim Brown framed innovation as the overlap of three lenses: what's desirable for people, what's feasible with technology, and what's viable for the business. Desirability is the human lens, and it "anchors in a deep empathy for users" (IDEO, Design Thinking). The other two lenses matter, but the discipline insists you start with the person.

The practical tools here are humble and repeatable. The empathy map, four quadrants for what a user says, thinks, does and feels, with the person in the middle, was created by Dave Gray and his team at XPLANE and popularised through the 2010 book Gamestorming. Nielsen Norman Group recommends it as "the first step in design thinking," precisely because filling it in exposes the gaps in what you actually know versus what you're assuming (NN/g, Empathy Mapping). The map's value isn't the pretty quadrants. It's the moment someone says "we don't have a single real quote for the says box", and the team realises it has been designing for a fiction.

The empathy map's job is to make your ignorance visible before it becomes expensive.

Try this before the next build decision: fill an empathy map for the actual user, and rule that the says and does quadrants may only contain things a real person was observed saying or doing. If those boxes are empty, that's your signal, go and watch someone before you spend another sprint guessing.

Where empathy quietly fails

Now the honest part, because HCD is sold with more certainty than it has earned. In a 2018 Harvard Business Review piece, NYU's Natasha Iskander argued that design thinking can be "fundamentally conservative", that even in the empathise step, it is still the designer who decides which parts of the user's experience count, which keeps power with the designer rather than the people being served (Iskander, HBR, 2018). That's a contested opinion, not a settled finding, design thinking has plenty of defenders, but it names a real trap. Empathy performed about people, in a workshop, with sticky notes, can feel like inclusion while excluding the very voices it claims to channel.

There's a second, simpler limitation worth stating: empathy is not a substitute for measurement. Caring deeply about a user tells you nothing about whether your solution works. That's why the standard ends every loop on evaluation, and it's why the related usability & guerrilla testing craft exists. Feeling for the user and testing on the user are different acts; a mature practice does both.

The move that fixes both: close the loop with the people, not just about them. Put a draft in front of five real users early and cheaply, and give those users a vote that can kill or reshape the work, not a comment box that arrives after the decision is locked. If your "empathy" never changes a roadmap, it's decoration.

A worked example

Take a small illustrative case (figures invented to show the shape of the work, not a real company). A regional clinic group wants to cut no-shows for appointments; the leadership team's instinct is to build an SMS reminder system. Confident motion, plausible solution.

A human-centred team starts a lap of the loop instead. Understand the context: they sit in the waiting room and ride along with the booking staff for two days, and they call fifteen patients who missed appointments. What they find isn't a memory problem. Most no-shows came from a cluster of patients who did remember, but couldn't get time off work, or couldn't arrange childcare for a mid-morning slot, or had moved and the only available appointments were now an hour's bus ride away.

The empathy map's says box fills with real quotes ("I'd have come if there was anything after 5"). The feels box shows shame, not forgetfulness, people who'd stopped rebooking because they felt judged for the last miss. An SMS reminder would have done almost nothing for this group, and might have made the shame worse.

The reframed requirement isn't "remind people," it's "make a kept appointment possible for working parents." The team prototypes two cheap changes, a block of early-evening slots, and a one-tap reschedule link instead of a phone queue, and tests them with eight patients before committing. In this illustrative scenario, no-shows in the affected group fall by a meaningful margin, and the expensive reminder platform is never built. The empathy didn't make them nice; it made them right about the problem, which is the only reason it pays for itself.

Frequently asked questions

Isn't this just "listen to your customers"? Why the jargon?

Listening is necessary but not sufficient. Customers tell you their proposed solutions ("send me a reminder"), not their underlying needs ("make a kept appointment possible"). HCD is the discipline of getting past the stated solution to the real need, and then testing your fix against reality before you scale it. The jargon is just shorthand for "don't skip the watching and the testing."

We have no budget and no research team. Can we still do this?

Yes, and the lightweight version is often better. Five users, watched directly, will tell you most of what a hundred-person survey would, this is the logic behind guerrilla testing. The empathy map costs a marker and an hour. The expensive part of getting it wrong is the build, not the research, so cheap research is the bargain.

How is this different from design thinking or the double diamond?

HCD is the philosophy, design from real human needs, evaluate against real humans. Design thinking and the double diamond are processes that operationalise it. You can practise HCD inside a double-diamond, a design sprint, or your own cadence; the constant is the human at the centre and the test at the end.

Doesn't empathy slow everything down?

It front-loads time you'd otherwise spend later, more expensively. The clinic team spent two days watching before building anything, and saved the cost of a platform nobody needed. The slow part of product work isn't research; it's shipping the wrong thing twice.

What if my team thinks they already "get" the user?

That confidence is the risk. The empathy map is useful precisely because it forces the team to back claims with observed evidence. Run it once with the rule that the says and does boxes need real quotes, and the gap between "we get it" and "we have evidence" tends to reveal itself fast.

Related in the Toolkit

Where to go next