Human-centered design: solving the right problem

Designing around people is often summed up with a fairly comfortable phrase:

Put the user at the center.

The problem is that the phrase explains little.

We can interview people, build personas, make empathy maps, and run usability tests and still end up designing a solution that does not address the problem they actually have.

Human-Centered Design is an approach to design that seeks to develop and improve products and services continuously, based on a deep understanding of people, their needs, and the contexts in which they act.

That implies quite a bit more than “asking the user what they want.”

It means understanding how someone lives a situation, identifying which problem is worth solving, looking at the system around that problem, and using evidence to learn before we commit to a solution.

Don Norman synthesizes this idea in four especially useful principles: focus on people, solve the fundamental problem and not only its symptoms, consider the whole system, and continually test and refine solutions.

Those four principles give us a much more concrete way to understand what designing around people actually means.

Start with people, not with the solution

Suppose a team receives this request:

We need an app to organize appointments.

The usual reaction may be to start immediately with features: calendar, reminders, cancellations, availability, or notifications.

But we still do not know whether an application is the answer.

First we need to understand what is happening.

The right questions look more like these:

• Who are the people we are trying to help?
• How does this issue affect their routine?
• How do they currently solve their problem?

These questions change the starting point.

Instead of studying only what our product should do, we start studying what people are trying to do.

That means observing needs, behaviors, abilities, limitations, and context.

Understanding a person in isolation is not enough either.

We need to understand the different contexts in which their activity happens: what they are trying to accomplish, which constraints they face, which other tools they use, whom they interact with, and what happens before and after our product.

That is where opportunities for improvement start to appear that we would hardly find by looking only at a screen.

Designing for people does not mean designing only for users

Even the word user can be too narrow.

A product can affect many people who never directly touch its interface.

Think of a system for checking in at an airport.

• There is the passenger.
• But also airport staff, agents, crew, operations, support, companions, and external systems.

Optimizing only the interaction of the person in front of a screen can shift the problem somewhere else.

That is why talking about people can be useful: it forces us to look beyond whoever is clicking.

Solve the right problem

This is probably the most important principle.

Design problems often arrive formulated as solutions:

• We need to add a search.
• We have to make a dashboard.
• We need artificial intelligence.
• The form has to have fewer steps.

The risk is to take that formulation as true and start solving it immediately.

Human-Centered Design proposes exactly the opposite: treat the initial problem as a hypothesis and spend time discovering the underlying causes before designing a response.

The useful questions here are:

• How do we define the problem people are facing?
• How do we know it is the right problem?

Imagine an ecommerce site with a high abandonment rate.

We might receive a request like this:

Checkout has too many steps.

Reducing steps seems like a reasonable solution.

But we investigate and discover that much of the abandonment happens because shipping cost only appears at the end.

The problem was not the number of screens.

It was missing information.

We could have designed an impeccable checkout to solve the wrong problem.

A symptom is not the same as a cause

If a person abandons, makes a mistake, calls support, repeats an action, or invents a workaround, that is evidence.

But it is not necessarily the problem yet.

We have to ask why it happens. And sometimes ask again.

Research is not only collecting opinions.

It is trying to build a sufficiently good explanation of what is going on.

The person is part of a system

Interesting problems rarely happen in isolation.

A person uses a product inside an organization, a process, a set of rules, other products, other people, technical limitations, incentives, costs, and time.

That is why another key question is:

• Who is affected by the problem we want to solve?
• How can we offer a solution that does not negatively alter other parts of the system?

Designing around a person does not mean ignoring everything else.

It means understanding how that person takes part in a system.

We could speed up checkout a great deal for the buyer by removing checks.

But if that multiplies fraud, inventory errors, or manual work in operations, we did not solve the problem.

We displaced it.

Look at the problem holistically

A person never uses a product under abstract conditions.

There is a context.

• They may be in a hurry.
• They may be tired.
• They may be using the phone with one hand.
• They may be working with noise.
• They may share a computer.
• They may be learning.
• They may depend on someone else.
• They may use our product together with other tools.

That is why it is worth asking:

• Which factors are relevant to the problem we are studying?
• Which aspects of the relationship between people and systems are we not considering?

Human-Centered Design does not mean accumulating data about a person.

It means trying to understand the situation in which an activity happens.

The unit of analysis should not always be the screen.

Often it is the activity.

Design with evidence, not only with empathy

Empathizing with people helps.

But it is not enough.

A team can feel a lot of empathy and still be wrong.

That is why design centered on people needs evidence.

• Observe.
• Interview.
• Analyze behavior.
• Prototype.
• Test.
• Measure.
• Observe again.

That introduces an important idea:

Centering design on people is not an initial Research stage. It is a way of working throughout the process.

A person does not validate a solution because they like it

Human-Centered Design does not mean:

We asked the user and they said they liked it.

What someone says is a source of evidence. Not the only one.

We can combine:

• what people say,
• what they do,
• what they can do,
• what happens in the product,
• and the results they finally achieve.

The team’s work is to interpret all of that.

Not to turn every request into a feature.

Design is iteration

An initial solution is a hypothesis.

We can think:

If we change X, we expect Y to improve because we learned Z.

Then we can build the cheapest representation that lets us learn something: a sketch, a prototype, a simulation, or a limited working version.

And test it.

If it works, we move forward.

If it does not, we learn.

That logic lets us detect errors while they are still cheap.

Iterating does not simply mean version 1, version 2, and version 3.

It means:

hypothesis → evidence → learning → new hypothesis

Improve continuously, do not design once

There is another important idea in the original framing of this piece: Human-Centered Design seeks to improve products and services continuously.

That changes how we think about launch.

Publishing a solution does not necessarily close the design process.

It lets us observe what happens when a hypothesis comes into contact with reality.

Some decisions will work as we expected.

Others will reveal new problems.

People, context, technology, and the organization will also change.

That is why a people-centered product is not simply a product that “did Research.”

It is a product whose process allows us to keep learning.

Centered on people does not mean ignoring business and technology

If we only designed what people desire, we could produce solutions that are impossible to build or sustain.

A good solution appears at the intersection of three questions:

• Desirability: does it respond to a meaningful need for people?
• Feasibility: can we build and operate it with the resources and capabilities available?
• Viability: can it be sustained for the organization?

Order matters.

If we start exclusively from technology — “we have AI, where can we put it?” — we are looking for a problem for a solution.

If we start exclusively from business — “we need to increase this metric” — we can end up optimizing something that generates value for the organization at the expense of whoever uses the product.

Human-Centered Design introduces another question:

Which problem is worth solving for the people involved?

A solution can be usable and still be insufficient

The original framing of this piece also pointed to something important: improving the experience is not only about making an interface easy to use.

We can look at a solution through dimensions such as usefulness, usability, desirability, findability, accessibility, credibility, and value.

That reminds us that:

• A product can be usable and not useful.
• It can be useful and not accessible.
• It can work technically and not feel trustworthy.
• It can solve a task and still not generate enough value to justify its use.

This complements Human-Centered Design well: first we need to understand which problem is worth solving, and then evaluate whether the solution actually improves people’s situation.

Human-Centered Design is not the same as Design Thinking

The terms often get mixed, but it is worth not treating them as perfect synonyms.

Human-Centered Design fundamentally describes an orientation of the design process toward people, their activities, needs, and context.

Design Thinking is a broader family of practices for addressing ambiguous problems through research, divergence, convergence, ideation, prototyping, and iteration.

We can use Design Thinking as a way of practicing design centered on people.

But running a workshop with sticky notes does not automatically turn a process into Human-Centered Design.

The four questions that keep the core

We can condense the whole article into four groups of questions, and add a fifth to close the cycle:

People

• Who are the people we are trying to help?
• How does the problem affect their activity?
• How do they currently solve it?

Problem

• What problem are we trying to solve?
• What evidence do we have that it is the right problem?

System

• Who else is affected?
• Which other parts of the system could change as a consequence of our solution?

Context

• Which conditions influence the situation?
• Which relationships, constraints, or behaviors are we still not seeing?

Evidence

• How will we check that our solution actually improves the situation?

It is not about designing for the user

There is a small difference in the words, but a large one in practice.

Designing for someone can still be a one-way process.

The team researches, interprets, decides, and delivers.

A more mature version of Human-Centered Design tries to involve people throughout the process, continually contrasting our interpretations with reality.

Not every project needs to reach a deep level of co-design.

But the principle is useful:

The more important a decision is for the people affected, the more dangerous it is to assume we understand their needs without involving them.

Designing around people is learning before committing

Human-Centered Design does not promise that we can eliminate uncertainty.

It does something more useful: it helps us reduce it progressively.

First we try to understand people.

Then we question the problem.

We look at the system.

We generate alternatives.

We build something.

We put it in front of reality.

We learn.

And we repeat.

The goal is not to follow a perfect process.

It is to avoid falling in love with a solution too soon.

Because a technically brilliant solution can still be useless if it solves a problem nobody had.

And an impeccable interface can still fail if it only works inside the scenario the team imagined.

Designing around people means remembering that our products do not exist inside Figma.

They exist inside systems, organizations, activities, and lives that were already happening before we arrived.

The work does not start by asking what we can design. It starts by understanding what is worth solving.

In short

Human-Centered Design is not only listening to users or running a workshop. It is an approach to design that starts from understanding people and contexts, questioning the received problem, looking at the whole system, and learning continuously through evidence and iteration.

Sources

• Don Norman. The Four Fundamental Principles of Human-Centered Design and Application. Texts on Human-Centered Design, fundamental principles, systemic design, and the evolution of the approach.
• ISO 9241-210. Ergonomics of human-system interaction — Human-centred design for interactive systems. Central reference for human-centered design applied to interactive systems.
• IDEO. What is Human-Centered Design?. Material on Human-Centered Design, Design Thinking, desirability, feasibility, and viability.
• Peter Morville. UX Honeycomb as a complementary frame for evaluating experience quality beyond usability.