Design Thinking Is 80% Theater. Here’s the 20% That Works.

Last quarter I ran a design thinking sprint on an AI agent project. Three weeks in, the only thing I’d produced was a wall of Post-it notes, two empathy maps, and a definition statement nobody on the engineering team could repeat. The agent itself had not moved one line of code forward (Related: when human oversight saved my AI projects).

Then I threw out 80% of the framework and kept the 20% that actually shipped the project.

Design thinking, stripped of consultant-speak, is a debugging loop for the gap between “what we think the user needs” and “what the user actually needs.” Most of what gets taught in corporate workshops is theater. The 20% that matters is something engineers have been doing for decades under a different name. They called it “writing tests against user behavior” or “asking the customer before shipping.”

This post is the 20%.

What design thinking actually is (and what it isn't)

Design thinking is a method for solving ill-defined problems through empathy, iteration, and prototyping. The phrase got popularized by IDEO in the 1990s and got pushed into the mainstream by d.school (Stanford’s Hasso Plattner Institute of Design) in the 2000s.

It is not:

– A 2-day workshop that produces a “How Might We” wall – A substitute for shipping – A set of sticky notes – Empathy theater where you roleplay as a user – A framework that works on any problem (it fails on well-defined problems — just ship the spec)

It is:

– A loop you run when you don’t know what to build – A way to make your assumptions falsifiable before you spend a quarter on them – A structured way to talk to 5 users instead of guessing about 5,000

The “design” in design thinking is not about visual design. It is about designing the problem statement before you design the solution. Most engineering disasters are caused by solving the wrong problem brilliantly. Design thinking is the antidote to that.

For what? The one question it answers

Here is the question design thinking exists to answer: “I have a problem. I don’t know what the user actually needs. How do I find out without spending six months building the wrong thing?”

If you already know what to build, you do not need design thinking. You need a spec, a sprint, and a JIRA board.

If you have a vague sense of a problem and a hunch about a solution, design thinking is the tool. The 5-stage model from d.school is the most popular way to run it. Let me walk you through it honestly, with what actually mattered for my AI agent project.

The 5 stages, with what actually mattered

1. Empathize

The instruction: go talk to 5 users. Watch them work. Don’t pitch. Don’t explain. Just observe.

What I did wrong the first time: I scheduled 5 calls with “users” who were actually other engineers on my team. We had a great time. I learned nothing.

What I did right the second time: I sat next to a real user (one of my client’s accountants) for 2 hours while she processed invoices. I watched her copy-paste the same 14 fields from email to ERP. Twice an hour. For 6 hours a day.

That is the only empathy work that mattered. Everything else was theater.

The point of the empathize stage is not to gather features. It is to see the gap between the official workflow and the actual workflow. Real users are not the people who fill out your survey. Real users are the people who do the work, and they have workarounds you have never heard of.

2. Define

The instruction: write a single sentence that captures the user’s need. “The user needs a way to X because Y, but current solutions Z.”

What I did wrong: I wrote a 2-page problem statement with 4 personas and a “scope boundary” section. Nobody read it.

What I did right: I wrote this on a sticky note:

> The accountant needs to get invoice data into the ERP in 30 seconds, because the manual paste takes 4 minutes per invoice and breaks her focus 12 times a day.

That is the only definition that mattered. The 2-page version was a defense of the bias I already had. The sticky note was falsifiable — I could test it.

A good definition is a target, not a brief. The moment it becomes a brief, you have stopped designing and started justifying.

3. Ideate

The instruction: generate as many solutions as possible. No judgment. Quantity over quality.

What I did wrong: I generated 11 ideas, picked my favorite 1, and started building.

What I did right: I generated 27 ideas, marked 8 as “could be tested cheaply,” picked the 3 dumbest-looking ones, and prototyped all of them. Two of the three looked terrible on paper. Both worked better in practice than my “favorite.”

The point of ideation is not to find the right idea. It is to widen the solution space before the prototype stage filters it. If you only ideate inside your existing assumptions, you have wasted the stage. The output of ideation is a portfolio of cheap experiments, not a chosen direction.

4. Prototype

The instruction: build the cheapest possible version of each candidate solution. Click-through mockups. Paper sketches. 20-line scripts. Whatever gets the idea in front of a user in 2 hours, not 2 weeks.

What I did wrong the first time: I built a full AI agent with a polished UI, integrations, and 3 fallback flows. 3 weeks of work.

What I did right the second time: I built 3 throwaway prototypes. One was a Google Form that pre-filled ERP fields and emailed them to me. One was a 20-line Python script that extracted data from a screenshot. One was a Loom video of me clicking through a Figma mockup.

The accountant tried all three in a 30-minute session. She picked the Google Form.

The point of prototyping is not to ship. It is to kill ideas cheaply. Every prototype that fails in 2 hours saved me 2 weeks of building the wrong thing. The 3 prototypes cost me 6 hours total. The “perfect” version would have cost me 3 weeks and shipped the wrong thing.

5. Test

The instruction: put the prototype in front of users. Watch them use it. Iterate.

This is the stage most people skip. They treat it as the final exam instead of the first real conversation.

What I did: I gave the Google Form to the accountant, watched her use it for a week, and kept a list of every place she hesitated. Hesitation is data. A user who pauses for 2 seconds on a button label is telling you the label is wrong. A user who clicks “Cancel” twice before submitting is telling you your success state is unclear.

Testing is not a checkbox. It is the actual feedback loop of the design thinking process. The other 4 stages exist to give you something worth testing. If you skip testing, you have built a hypothesis and shipped it as a fact.

The popular theories (and which one to use when)

There are three frameworks you will see. Pick by problem shape.

d.school’s 5-stage (Empathize, Define, Ideate, Prototype, Test) — the one I walked through above. Best for: ill-defined problems, new products, zero user research so far. Downside: linear. Real projects loop back, but the model pretends they don’t.

Double Diamond (British Design Council) — Discover, Define, Develop, Deliver. Two diamonds, each split into a divergent phase and a convergent phase. Best for: medium-complexity problems, teams that need a shared vocabulary. The visual is sticky. The framing (“converge on the right problem, then converge on the right solution”) is genuinely useful.

IDEO’s human-centered design — the original 1990s framing. Less prescriptive than d.school, more emphasis on “deep hanging out” with users. Best for: consumer products, services, social impact work. The downside: it is more of a culture than a process. Hard to teach in a workshop.

If you are doing this for the first time, use d.school’s 5-stage. It is the easiest to teach, the easiest to run, and the easiest to critique. The other two are refinements for specific contexts.

How to actually use design thinking in your daily work

Most of you reading this are not designers. You are engineers, founders, PMs, or operators. Here is how to apply design thinking without booking a workshop or buying a stack of Post-its.

For engineers: Before you build the next feature, write a 1-sentence definition of the problem. Then write a 1-sentence description of how you will know the feature worked. If you cannot write the second sentence, do not start building. This is design thinking stripped to its load-bearing components.

For founders: Talk to 5 users a week. Not 5 customers. 5 users — the people who use the product, not the people who pay for it. Pay users and use users are not the same person. Most of your churn is from use users, not pay users.

For PMs: Run a 90-minute prototype session every Friday. Take the riskiest assumption in your current sprint, build a 30-minute mockup, and put it in front of 1 user before Monday. The output is not a feature. The output is a falsified assumption or a validated one. Both are useful.

For operators / non-builders: Before you change a process, run the empathize stage on the people who actually do the process. The gap between the SOP and what they actually do is where the bugs are. Document the workaround before you fix it.

The pattern is the same across roles: empathize (see the actual problem) → define (state it falsifiably) → prototype (test the cheapest version) → test (watch real use) → repeat.

Most of design thinking is not the framework. It is the discipline of running the loop before you have the resources to run it “for real.” Teams that learn the loop skip the loop later. Teams that skip the loop in the small pay for it in the large.

—

Design thinking did not fail my AI agent project. The 80% I kept from the workshop failed it. The 20% I kept — sit next to a real user, write a falsifiable problem statement, build 3 throwaway prototypes, watch hesitation — shipped it. The framework is a crutch. The loop is the work.

Also interesting: what actually broke when I let AI run things