Design Thinking Was Oversold, So Use It on Purpose

Design thinking got sold as a cure for everything. Empathize, ideate, prototype, cover the walls in Post-its, and big problems fall down. Your team probably ran a few of those workshops. Some helped. Some ended with a stack of sticky notes and nothing built. The mistake leaders make is treating the method as a religion, all in or all out. It is a tool. Tools have a job and a limit. Your job is to know which is which before you book the room.

The deep cut

• Empathy without implementation is theater. IDEO's workshops made great stories but Jake Knapp watched few ideas reach production.
• A method that skips who pays fails public work. Cyd Harrell warns that the hard part in civic tech is funding and delivery, not new ideas.
• Own the last step or don't start. Design stewardship, as Dan Hill frames it, holds the strategic payoff, not just the deliverable.

What it was actually good at

Strip away the hype and the method did one thing well. It got people from different teams in a room at the start of a project, talking before anyone locked in an answer. Enrique Allen calls that cross-team exchange the real value. Erica Eden puts it plainer: the process gave ideas weight for people who had no language for creative work.

That is not small. Before this, in many shops, work was a solo job behind a closed door. The five steps, empathize, define, ideate, prototype, test, gave a mixed group a shared script. If your team keeps skipping the shared start and jumping to solutions, that is the part worth keeping.

Where it turns into a show

The method has a hole where the ending should be. Some versions of the six steps drop implementation entirely. The agency roots explain it: a firm shows up on a timeline, runs the workshop, hands over recommendations, and leaves before the pilot. The exciting part is cheap. The building is expensive and slow.

So you get "innovation theater," boxes checked with no real shift. Knapp saw it at Google, where workshop energy faded and decisions got made the old way, by a few people selling finished ideas up the chain. If your workshops produce excitement and no shipped work, you are running the show, not the method.

The empathy trap

Empathy is step one, and it is where teams fool themselves. You can feel deep for a user and still not know their world. When IDEO reimagined school lunch, Kyle Cornforth looked at the ideas and asked if anyone had talked to someone who works in a school. The ideas had energy. They had no context.

That is the risk of "beginner's mind" sold as a feature. A fresh eye helps, but it is not a substitute for people who live the problem. Staney Joseph pushes teams to ask whether they are solving the bigger problem or just the narrow one in front of them. Pair your outside energy with real domain expertise, or you get confident answers to the wrong question.

Stop solving problems, start owning outcomes

Calling yourself a problem solver sounds humble. It is a way to grab the win and duck the mess. The AIGA piece names it: design has learned to monopolize the privilege of a solution while rejecting responsibility for the problem. A tidy "problem package" lets a team feel done when the real work is just starting.

Dan Hill's answer is design stewardship. He built a low-carbon building in Finland and treated it as a MacGuffin, an excuse. The building mattered less than the fire code it changed and the timber industry it lifted. A problem solver ships the building. A steward tracks what the building sets in motion. For your team, that means owning the outcome months out, not the deliverable at handoff.

How to use it on purpose

Decide before you start, not after. Ask what you actually need. If the need is getting a split team aligned on a hard problem, run the workshop; the shared language earns its keep. If the need is delivery and funding, the time-boxed workshop is the wrong shape. Harrell notes the mismatch: commercial design runs on short cycles, policy runs on years.

Then name who owns the last step before anyone lifts a marker. No implementation owner, no workshop. Give it a taxonomy if that helps; Ian Gonsher argues for naming the kind of design work you are doing so you pick the right fit. Use the method where it fits and skip it without guilt where it does not. That is the whole discipline.

Three questions for your team

• Who owns implementation on this, and are they in the room today? If the answer is a recommendation handed to someone else, you are staging theater, not building.
• Have we talked to people who live inside this problem, not just people who feel for them? Empathy without a school employee in the conversation is a guess with confidence.
• Are we tracking the deliverable or the outcome it sets off? Name the strategic payoff you are stewarding, or admit you are just shipping the building.