Design Thinking

For a long time, deciding what to build started from one of two places: what the team could build, or what the person with the final say wanted. Both answers live inside the company, so nobody ever had to leave the office to get one.

The gap only showed up after the work shipped. Three months of effort goes live and two percent of users touch it in the first month. Nothing is broken, nothing looks bad, and still nobody uses it. Scroll back through the meeting notes and the whole thing traces to a single line near the beginning — "users are probably frustrated by this" — said by someone who had never met such a user, agreed to by people who hadn't either.

So planning meetings ended the same way every time. When both sides are guessing, the argument gets settled by volume, and usually the more senior guess wins. The people who disagreed back down because they have nothing to put on the table. When the feature lands and goes unused, the explanation is that marketing was thin, or that users haven't gotten used to it yet. There was never a way to find out which guess was wrong, so the wrong ones and the right ones stayed indistinguishable and the next quarter started the same way.

Design thinking is a proposal to move that starting point. Begin with who is stuck and in what situation rather than with what is buildable, and get things wrong on paper instead of after three months of engineering. The name comes from the fact that the steps were written down by watching how designers already worked, not because only screen people can use them. The same five steps get used to fix a support escalation process or rewrite how time off gets requested internally.

The design process area holds three methodologies for shaping the order of work. This one covers the attitude. Checking which stage the team is standing in, or forcing a decision inside five days, belongs to the other two; this one supplies the principle that work starts from users and the five steps that turn that principle into something a team can schedule.

There is one branch under design thinking: the five steps the approach proposes, taken in the order they are written.

Broadly, the first two hold the problem still and the last three test the solution. Compared with other methodologies, the character of this one is how much time it spends up front. On a two-week project, the whole first week goes to the first two steps and screen work starts in week two. Teams that have never worked this way find the first week uncomfortable, because for five days there is nothing to show anyone.

1. Empathize — understand the user's situation and feelings. Instead of imagining it at your desk, go ask and watch. Five to eight people, forty-five minutes each, and if possible sitting beside them while they work. The shape of the question decides what you get. Ask "why don't you use it" and people invent a plausible reason; ask "when was the last time you used it and what was going on that day" and you get an actual scene. When what someone says conflicts with what they do, write down what they did. People are reliable narrators of what happened and unreliable ones about why they did it. Mixing in people at both extremes helps too — someone who opens a hundred documents a day next to someone who opens two a month will surface friction that the middle of the range hides.
2. Define — narrow the problem down to something sayable. Put every fragment from the interviews on the wall, group the similar ones, and turn the thickest cluster into one sentence. That sentence carries four parts: who, in what situation, needs what, and why it doesn't work right now. "Collaboration is awkward" is not an output of this step. "Someone who joined last week has to catch up on past decisions, but those decisions are scattered across ten meeting notes and there's no way to tell which one is current" is narrow enough for the next step to filter against.
3. Ideate — spread solution candidates wide. Three rules: no judging good from bad, hit a count first, and build variants on top of what other people put up. Raise feasibility here and the list stops before it reaches ten. Starting out loud in a room pulls everyone toward whoever spoke first, so people sketch alone on paper for eight minutes and then reveal one at a time. Gather about forty, then pick three that point in genuinely different directions. Three near-identical variants of the same idea give the next step nothing to compare.
4. Prototype — build the chosen ideas fast. What gets made here is not a product but a prototype, something put together temporarily to see how people react. Eight screens drawn by hand on paper qualify. The budget is half a day to two days; anything longer means the question being tested is too big and should be split. Keeping it cheap has a purpose. You can only take "I don't like this" at face value if you were ready to throw the thing away.
5. Test — get confirmation from users. This is not a session for showing work and collecting opinions; it's one for assigning a task and watching where people get stuck, which has its own name, usability testing. Instead of "how does this screen look," say "find what was decided in last week's meeting," then record where the hand stops and what gets clicked by mistake. Five people are usually enough to expose the visible problems, and the ones that show up in three of the five are the ones worth fixing first.

The five steps do not run in a straight line. Where you go back depends on what turned out to be wrong. If people can't find the button, return to step 4 and fix the screen. If they find it and say they have no reason to press it, return to step 3 for candidates in another direction. If they say they never intended to do that task at all, it's step 2, because the problem statement was wrong. Every loop forces that judgment, and how accurately a team makes it is close to what skill with this approach means.

The places it doesn't fit are clear enough. Work where a contract or a law already fixed what gets built, leaving only the how, has no use for it. Security policy and accounting rules land here too: if users say something is painful but the room to change it is zero, the time spent on the first two steps evaporates. The same goes for situations where users can't be reached — an empty first step leaves the other four standing on guesses. And with three days on the clock this is too slow, which is the point where a five-day format fits better. None of this makes the approach wrong for the job; it means the conditions it depends on, reachable users and room to change the answer, are not present.

"That's our guess, not theirs. Let's go back to empathize and talk to five people who actually use it this week."

The evidence is assumption rather than observation, and the ask is to return to step one, not to push the deadline.

"We're spreading options right now, not picking one. Whether it's feasible comes later."

Raising feasibility during the divergent stretch kills candidates early.

"The prototype looks too finished. People assume it's done and stop telling us anything."

High polish makes users swallow their criticism, so the next round should go out rougher.

At Pagedeck this came up during the quarter the notification settings screen got rebuilt. It started with twenty support tickets saying there were too many notifications, and the first meeting produced one idea: add more toggles for turning notifications off. Noa asked to talk to six users before building it. Not one of them had turned notifications off. They were afraid of missing something important, so instead they scanned the notification list top to bottom every morning and cleared it by hand.

The problem sentence Noa wrote afterward was not that toggles were missing. It was that a user can't tell within three seconds whether a given notification matters to them. Changing the sentence changed the candidates. The team sketched three options on paper, ran them past five users, and the one that pulled mentions of you to the top was where hands moved fastest. Theo shipped it in two weeks and tickets dropped from twenty a month to three. Had the team built the toggles, the screen would have grown busier and the morning scanning ritual would have survived intact.

The most common mistake is reading the five steps as a procedure you pass through once in order. Every diagram draws them as five arrows in a straight row, so it's a fair reading. In practice the sequence exists so that teams go back. Facts from a later step overturning an earlier judgment is the normal case, and a team that doesn't turn around at that moment wastes the four months behind it. Teams that only walk forward leave no slot in the schedule for acting on what the final test found. The findings get filed, the release happens on the original date, and the same screen gets rebuilt from scratch next quarter. Leaving a week of slack after the last test round is what separates a team that loops from one that only looks like it does.

The second is believing that lifting the idea-generation step out on its own counts as doing design thinking. It's the most visible and most enjoyable of the five and it fits in an afternoon, so it's an easy one to take alone. The trouble is that without the first two steps, the forty ideas on the wall came from the people in that room rather than from users. Guesses as raw material produce variations on guesses, however many you generate. What survives is one photo of a wall covered in sticky notes, and two months later the same people reopen the same argument from the beginning.