A persona poster on the wall is not a design. It is a guess with a name. The people who use the service, the customer on the phone, the operator who has to clear the exception, the colleague who inherits the case at 4pm, are usually somewhere else while the room agrees on what they would want. The work of human-centred design is to close that gap before money is spent building the wrong thing.
Nielsen Norman Group's Design Thinking 101, written by Sarah Gibbons and last reviewed on 15 July 2026, puts the ideology in plain terms. A hands-on, user-centred approach to problem solving can lead to innovation, and innovation can lead to a difference a customer can feel. The same article quotes Jakob Nielsen: a wonderful interface solving the wrong problem will fail. That sentence is the whole argument. Craft on the wrong problem is still a miss.
Start with what people do
Gibbons splits the work into six phases inside a larger flow of understand, explore and materialise: empathise, define, ideate, prototype, test and implement. The first phase is not a workshop icebreaker. It is research. Talk to a range of actual users. Watch what they do. Ask where they stall. For an onboarding example, the article says the point is to gather enough observation that the team can see the user's situation, not the company's org chart.
Corporate teams skip this because the calendar is already full and because someone senior already has a solution in mind. The skip feels efficient. It is how you get a journey map that describes internal handoffs and calls them the customer experience. If the map can be drawn without a single conversation outside the building, it is an internal process picture. Hang it in the operations room. Do not call it research.
The design thinking workshop is the day we use when a team needs to do this on a live problem, not on a canned case. The room leaves with a problem worth solving and a rough prototype, not with a new vocabulary.
Define the problem in their words
The define phase is where observation becomes a problem statement. Gibbons's point is to combine the research and see where the problems actually sit, including the unmet need that shows up across more than one person. A useful statement names the person, the situation and the pain, in language they would recognise. "Improve NPS" is a target. It is not a problem. "New customers abandon the identity check because the screen asks for a document they do not have with them" is a problem. You can test it. You can be wrong about it.
This is also where human-centred work parts company with a brainstorm. Ideation comes after the problem is sharp. Gibbons describes ideation as a range of ideas aimed at the unmet need, with quantity ahead of polish, and with the team building on each other's sketches. If you ideate before you define, you generate options for a problem you have not earned. The sticky notes will look busy. The build will still miss.
Make it tangible, then take it back
Prototype, in this account, means a real enough representation that you can see which part of the idea works. A wireframe, a script, a service walk-through with a colleague playing the customer. The goal is not to impress a steering committee. It is to learn which assumption breaks on contact.
Test means going back to users and asking whether the thing meets the need, and whether it changed what they think, feel or do. Put the prototype in front of people who were not in the room that made it. If you only test it on the team that designed it, you will hear politeness. Politeness is not evidence.
Then implement. Gibbons calls this the phase most often forgotten, and quotes Don Norman's line that we need more design doing. Design thinking does not excuse you from shipping. A concept that never reaches the user did not change their day. Milton Glaser's line in the same piece is the right temperature: taking an idea from your head into something real is slow, difficult work. If it feels like work, you are probably doing it.
What this looks like inside a company
You do not need a design department to run the sequence. You need access to the people who use the service, a block of time, and a sponsor who will accept a killed idea. A practical cut for a corporate team:
- Pick one service moment that already hurts. A drop-off, a complaint theme, a queue. Not a vision for the year.
- Spend the first hours with users or with the staff who speak to them every day. Write what you saw, not what you hoped.
- Write one problem statement the user would recognise. If they would not recognise it, it is still your framing.
- Generate options only against that statement. Cut hard. Keep two.
- Build the thinnest version a stranger can react to in the same week.
- Decide: proceed, change or stop. Record the decision where the next team can see it.
The sixth step is where corporate programmes go quiet. A prototype that nobody is allowed to kill becomes theatre. A prototype that ships without the test becomes the old habit with a new skin. Human-centred work is the discipline of letting the user's evidence outrank the room's preference.
Where teams fool themselves
Three substitutions show up again and again.
A survey is not empathy. A score can tell you something is wrong. It rarely tells you the sequence that made it wrong. Sit with the person, or listen to the call.
A persona is not a user. A persona is a summary you wrote. It is useful after you have met people, as a reminder. It is a fiction if you wrote it first.
A journey map of internal steps is not the customer's day. Draw both if you must. Label them honestly. The customer's version includes the wait, the repeat explanation and the moment they give up. The internal version includes the system that caused it. You need both, and you should not pretend they are the same picture.
Gibbons also notes that the phases are cyclical, not a line you walk once. Teams go back to empathise and define after a prototype, because only then can they see what they failed to ask. That loop is a feature. A programme plan that forbids returning to research has optimised for a slide, not for a service.
What to ask a vendor or an internal team
Before you fund a design effort, ask for the users, the problem statement, the prototype and the decision. If the pack has frameworks and no names of people who were observed, you are looking at a method lecture. If it has ideas and no test, you are looking at taste. Taste is allowed in the room. It is not a substitute for the person who has to use the thing.
Keep the Nielsen line on the wall, in your own words if you like, but do not soften it. An elegant flow that solves a problem nobody has is still a failure. The design thinking workshop exists so a cross-functional team can do the unglamorous version: observe, define, make something rough, and test it before the build estimate arrives.
Human-centred design is not a poster about empathy. It is a sequence that starts with people who are not you, and ends when something in their day is different. If you cannot point at that difference, you have not finished. You have decorated a guess.
Source: Sarah Gibbons, "Design Thinking 101", Nielsen Norman Group, 31 July 2016, last reviewed 15 July 2026. https://www.nngroup.com/articles/design-thinking/