When we run a design day I ask who in the room has spoken to a person who uses the service. People point at a persona they printed and pinned to the wall. They have already spent the morning agreeing what that persona would want, and the person who rang the call centre yesterday never got a seat.
Jakob Nielsen said a wonderful interface solving the wrong problem will fail. You can feel that in the steering pack. The flow looks elegant. The team wrote the problem on a Tuesday, and nobody who uses the service has confirmed it. You can spend a lot of craft there and still miss.
Start with what people do
The useful sequence is plain. Understand, then explore, then make the thing real. Inside that sit six jobs: empathise, define, ideate, prototype, test and implement. Jakob Nielsen's group describes the whole approach as hands-on and user-centric, the sort of work that can lead to innovation, and from there to differentiation and a competitive advantage. You get that when the service changes in a way a competitor has to catch, because you watched where people stall and then you shipped the fix. A wall of sketches will leave you with a wall.
The first job is research. Talk to people who use the service. Watch what they do. Ask where they stall. On an onboarding problem, that means enough observation to see the situation from their side, away from the org chart.
Corporate teams skip this because the calendar is full and someone senior already has a solution in mind. The skip feels efficient. It produces a map of internal handoffs that the team then calls the customer experience. If you can draw it without a single conversation outside the building, hang it in the operations room and call it a process picture.
Talk to the people who use it
The design thinking workshop is the day we use when a team has to do this on a live problem. They leave with a problem worth solving and a rough prototype they can put in front of someone who stayed out of the room.
A problem in their words
Observation has to become a problem statement a user would recognise. Name the person, the situation and the pain. "Improve NPS" is a target the executive team already has. "New customers abandon the identity check because the screen asks for a document they left at home" is a problem. You can test it. You can be wrong about it.
Ideas come after the problem is sharp. You want a range of options, quantity ahead of quality, the team building on each other's sketches. Generate the options first and you are answering a question you have yet to earn. The wall looks busy. The build still misses the document the customer left at home.
Make it, then take it back
A prototype is real enough that you can see which part of the idea works. The range of forms is in 12 types of prototypes. A wireframe, a script, a walk-through with a colleague playing the customer. You are there to learn which assumption breaks. If you built the prototype to impress a steering committee, you pointed it at the wrong audience.
Take it back to people who stayed out of the room that made it. Ask whether it meets the need, and whether it changed what they think, feel or do. Test it on the team that designed it and you will collect politeness. Politeness will tell you nothing about the identity check when the document is at home.
Then ship it. Don Norman put the forgotten part in four words: we need more design doing. A concept that never reaches the user leaves their day alone. Milton Glaser said the same thing from the other side. Taking an idea out of your head and turning it into something real is a long, difficult process. If you are doing it right, it feels like work.
A prototype you can show
Implement is the phase teams forget most often. The steering group can see the prototype. The changed service takes longer, and the customer is the only person who can use it. Ship the smallest change a user would notice, name who owns it after the workshop, and go back to watch whether the stall is still there. A concept deck skips that return.
Inside a company
You can do this without a design department. You need access to the people who use the service, a block of time and a sponsor who will accept a killed idea. Pick one moment that already hurts. A drop-off, a complaint theme, a queue. Spend the first hours with users, or with the staff who speak to them every day, and write what you saw. Write one problem statement the user would recognise. If they would reject it, you are still using your framing. Generate options only against that statement. Keep two. Build the thinnest version a stranger can react to in the same week. Decide whether to proceed, change or stop, and write the decision where the next team can see it.
The decision is where corporate programmes go quiet. A prototype nobody may kill becomes a performance. A prototype that ships without the test becomes the old habit with a new skin. The discipline is letting the user's evidence outrank the room's preference, including the sponsor's.
Substitutions that feel like research
A survey 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, before you treat the score as a brief. Write the persona after you have met people, as a summary. Write it first and the room will defend a fiction because it has a name.
A map of internal steps is the company's day. The customer's day includes the wait, the repeat explanation and the moment they give up. Map that in a customer experience workshop. Draw both if you must, and label them. The internal version includes the system that caused the wait. Call them the same picture and you will redesign the handoff while the wait stays.
The phases loop. Teams go back to the research after a prototype, because only then can they see what they failed to ask. A plan that forbids that return has optimised for a slide with a single arrow. The service will ignore the arrow.
Before you fund it
Ask for the users, the problem statement, the prototype and the decision. If you see frameworks and no names of people anyone observed, you are funding a method lecture. Ideas with no test mean you are funding taste. Taste can sit in the room. It cannot replace the person who has to use the thing on a Tuesday, with the document they actually have.
Keep Nielsen's line where the team will see it. An elegant flow that solves a problem nobody has still fails. The design thinking workshop is the unglamorous version. You observe, you define, you make something rough and you test it before the build estimate arrives.
The sequence starts with people who are outside your building. It ends when something in their day is different. If you cannot point at that difference, the customer is still abandoning the same screen.
The decision before the budget
Jakob Nielsen's design thinking overview is the public note behind that line.
