Design Thinking

By Clara

Last updated June 13, 2026

TL;DR

• Design thinking starts with direct observation of real users.
• The five stages are iterative, not a linear checklist.
• IDEO and Tim Brown brought the methodology to business audiences in 2009.
• Programs fail when internal stakeholders replace real users — design theater.
• Pair it with systems thinking to navigate organizational constraints.

Design thinking is a teachable innovation process that makes user observation the first filter. It works when teams genuinely watch users and iterate; it fails when organizations perform the stages without real access.

What is design thinking?

Design thinking is a human-centered approach to innovation that begins with direct observation of real users, frames problems from their perspective, generates a wide range of possible solutions, and validates them through rough prototypes and iterative testing. Its defining structural feature is that desirability — whether people actually need the solution — is the first filter, not an afterthought.

Most teams start with a solution. Design thinking starts by watching real users before proposing one, then builds from what that observation changes. It is a structured, teachable process — not a creative talent. Any team can learn and apply it.

Tim Brown formalized the framework in Change by Design (2009), defining it as:

“A human-centered approach to innovation that integrates the needs of people, the possibilities of technology, and the requirements for business success.” IDEO U

— Tim Brown, Change by Design, 2009

The methodology organizes around three lenses, each necessary, none sufficient alone:

• Desirability: Does this solution address something people actually need?
• Feasibility: Can it be built with available or near-term technology?
• Viability: Can it sustain an organization economically over time?

Most product teams already think about whether something is wanted. They also think about whether it’s buildable and sustainable. The difference is which one you treat as the first filter. Design thinking makes desirability the gate you have to pass through first. That forces a question most processes avoid: has anyone on the team actually watched the people this solution is supposed to serve? It’s like asking who wants to eat the meal before you design the kitchen. Once you put desirability first, assumptions stop being good enough.

Herbert Simon formulated the intellectual basis in 1969. Design, he argued, is at root a:

“course of action aimed at changing existing situations into preferred ones.” Herbert Simon

— Herbert A. Simon, The Sciences of the Artificial, 1969

“Preferred” sounds harmless until you ask: preferred by whom? And the harder question is how. Simon’s answer comes across as almost inevitable once stated: you figure it out by observing the people who concretely inhabit the situation you want to change. The five stages are just a delivery mechanism for that idea. They aren’t a creativity technique you can bolt onto a normal process; they are the process, because without them the “preferred” state is just a guess.

IDEO U makes the practical implication explicit: “By focusing on human needs, design thinking ensures that solutions are technologically feasible, economically viable, and deeply relevant to the people they serve.” The word “relevant” is doing work. Relevance is not discovered by asking people what they want. It is discovered by observing what they do.

This distinction — between stated preferences and observed behavior — is the axis on which design thinking turns. Every structural feature of the methodology exists to enforce it.

[Internal link: see Human-Centered Design and Innovation Processes]

Where does design thinking come from?

Design thinking’s intellectual lineage begins with Herbert Simon’s 1969 argument that design is a rational problem-solving discipline, passes through Rolf Faste and David Kelley’s Stanford curriculum in the 1980s–1990s, and reached corporate audiences through Tim Brown’s Change by Design in 2009.

Herbert Simon and the epistemological origin (1969)

The founding argument came not from a design firm but from a Nobel laureate in economics. In The Sciences of the Artificial, Simon established that design is a cognitive discipline — a planned “course of action aimed at changing existing situations into preferred ones” — applicable to systems, organizations, and policy as much as to physical objects.

Simon located the designer’s task in the gap between the existing state and the preferred state. Everything hinges on that gap. Closing that gap required understanding who inhabits the existing state and what they need from the preferred one. That is design thinking’s epistemological kernel: user observation is not optional research. It is how any team learns what the preferred state actually looks like, as opposed to what the organization assumes it looks like.

This intellectual lineage had a years-long head start on IDEO. When design historians and consultants argue over whether design thinking is a method or a repackaged workshop format, tracing the vocabulary back past IDEO to Simon’s formulation resolves part of the dispute, because he was doing philosophy, not facilitation.

Rolf Faste, David Kelley, and Stanford’s d.school

The institutional bridge from Simon’s theory to a teachable practice was built at Stanford. Rolf Faste introduced “human-centered design” as a formal curriculum discipline in Stanford’s Product Design program in the 1980s — coining the term that became the methodology’s organizing principle. David Kelley, who founded IDEO in 1991, developed that curriculum further and later co-founded the Hasso Plattner Institute of Design at Stanford, the d.school.

The d.school’s structural contribution was making the methodology cross-disciplinary by design. Engineers, nurses, social scientists, and business students took the same courses. The five-stage framing that most practitioners now use emerged from d.school teaching materials and spread globally through alumni who exported it to organizations across sectors. ABC Nightline

Tim Brown and IDEO (2009 and after)

The crossover to mainstream business audiences happened through Tim Brown’s Change by Design (2009). Brown translated the d.school’s workshop methodology into an argument for corporate innovation: teams that began with user observation before generating solutions consistently produced better outcomes than those that didn’t. IDEO

[Internal link: see User Research]

What are the five stages of design thinking?

The five stages of design thinking are Empathise, Define, Ideate, Prototype, and Test. They are iterative, not linear: teams move back and forth between stages as new evidence emerges, and returning to an earlier stage after testing is the process working as intended, not a failure.

Once user observation is skipped, the rest of the process slides into decoration. The five stages from Empathise to Test are the delivery mechanism for that claim — iterative by design. IDEO U

• Empathise — Direct observation, not surveys. Surfaces workarounds, unarticulated frustrations, and behaviors that aggregated data smooths over.
• Define — Synthesizes observations into a point-of-view statement that opens the solution space rather than closing it.
• Ideate — Divergent phase: quantity before quality, judgment deferred, to push past the first ring of obvious solutions.
• Prototype — Rough, cheap artefacts designed to generate feedback — cardboard, wireframes, role-plays — not to present conclusions.
• Test — Structures discovery of what the team still doesn’t understand about the user.

IDEO U is explicit that the sequential presentation is a teaching device: “We teach the phases of design thinking as linear steps, though practicing design thinking rarely looks so tidy. Some of these phases end up happening several times, and you may even jump back and forth between them.”

Executives often look at the looping structure and try to straighten it into a linear plan. They have it backwards. The method is the whole point. Each time a prototype sends you back to Empathise, the method is doing the one thing a linear process can’t: catching you being wrong before you’ve built too much. Testing isn’t there to validate your idea. It’s there to expose the gaps in your model of the user. A process that never sends you backward is a process that never learns.

[Internal link: see Rapid Prototyping] [Internal link: see User Research]

How do the five stages work in practice?

Each stage has a distinct logic that is easy to name and easy to skip. What separates teams that generate actionable insight from those that generate sticky notes is understanding what each stage is trying to accomplish — not just what activities it involves.

Empathise: observe, don’t survey

The foundation of design thinking is ethnographic — going where users are and watching what they actually do. Practitioners call this needfinding (the structured fieldwork practice of surfacing unarticulated user needs before any problem statement has been written). It is where observation most often contradicts the team’s assumptions. Stated preferences and actual behavior routinely diverge. ABC Nightline

Airbnb’s origin is often used to illustrate the gap. Company accounts describe how observation revealed that guests wanted local connection and authentic experience, not just cheaper accommodation, and that hosts wanted supplemental income plus connection, not merely to rent rooms. Neither insight was available from quantitative data.

Define: frame, don’t brief

A product brief specifies a solution category: “we need a better checkout flow.” A design thinking point-of-view (POV) statement specifies a user need: “busy parents need to complete a purchase in under two minutes without losing their place.” The difference between these two framings is not semantic. The brief constrains ideation to checkout-flow improvements; the POV statement opens it to any mechanism that addresses the underlying time and attention constraint. IDEO U

A well-framed POV statement does not presuppose a solution; it opens the solution space rather than narrowing it. The d.school operationalizes this through “How Might We” prompts, a sentence-stem technique that converts a field observation into an open-ended design challenge. The example — “How might we help busy parents complete checkout without losing their place?” — shows how ideation targets a real user constraint rather than a feature assumption. Framing a good problem statement requires resisting the organizational reflex to validate problems that are already identified. The Define stage’s job is to find the right problem — not confirm the one the team assumed going in.

Ideate: diverge before you converge

The Ideate stage’s primary output is quantity, not quality. Its rules — defer judgment, go for volume, build on others’ ideas, encourage wild concepts — exist to push teams past the first ring of obvious solutions. ABC Nightline

The IDEO shopping cart documentation is specific about the social contract required: “The hardest thing for people to do is to restrain themselves from criticizing an idea.” Premature convergence collapses ideation before divergent thinking has occurred. The organizational efficiency reflex, cutting off ideas the moment they arise, is the most common way this stage gets corrupted. When evaluation arrives during generation, the unexpected ideas die first, and the obvious ones survive.

Prototype: build to learn, not to present

Design thinking prototypes are not presentations of finished thinking. They are hypotheses made physical, cheap enough to discard when the hypothesis is wrong. IDEO’s formulation captures the economics:

“Enlightened trial and error succeeds over the planning of the lone genius.” ABC Nightline

— ABC Nightline / IDEO, The Deep Dive, 1999

A rough prototype that reveals a fatal flaw before engineering starts compresses months of rework into a morning of discovery. The deliberate roughness of design thinking prototypes also serves a social function: a polished model signals completion and invites validation rather than critique. A cardboard prototype signals tentativeness and invites honest feedback.

Test: discover what you still don’t understand

Testing in design thinking is not product validation. It is a structured method for generating the next round of questions. When a prototype surprises a user, whether they use it in a way the team did not see coming or avoid a feature the team thought was central, that surprise gives the team new input and points to where its model of the user missed. Teams that treat testing as validation run a different process: one that tends to confirm existing beliefs rather than challenge them. IDEO

[Internal link: see Human-Centered Design]

Why does the stage sequence matter? The case for starting with the user

The order of the stages is the mechanism, not a pedagogical convention. Conventional product development can include user research — many teams do. What it cannot easily do is make that research load-bearing before solution generation begins, because organizational incentives run the opposite direction.

The conventional sequence and what it costs

In many product teams, a founder, PM, or executive arrives with the idea first. Often, this happens before any research. User research is then brought in to check it. That catches the worst mismatches, but it can’t discover anything the idea’s owner didn’t already suspect. Validation research is designed to confirm. It answers “does this work for users?” rather than “what would actually work for users?” — and if you’re stuck on that first question alone, research isn’t what’s happening. You’re inspecting your own assumptions.

McKinsey’s 2018 research found that more than 40 percent of surveyed companies still did not talk to end users during their development process. That statistic suggests the default is organizational: most teams still build without direct user observation. Design thinking explicitly inverts that norm by making observation the first gate.

What the sequence reversal actually prevents

The stage ordering calls for completing Empathise before Ideate — but in practice, this forces organizations to confront a specific discomfort: genuine user observation delays visible output. Spending two weeks in the field before generating a single solution concept looks like lost time to any organization that measures progress by deliverables.

The cost of discovering a fundamental mismatch between a solution and user needs scales with how far development has progressed. Discovering it in the Empathise stage costs a field trip. Discovering it after twelve months of engineering costs the twelve months — plus the pivot. ABC Nightline Rough prototyping and early testing compress the discovery window dramatically. This is the economic argument for the sequence: it front-loads the failures that are cheap and defers the commitments that are expensive.

The learnable-at-scale argument

Design thinking’s adoption at organizations like IBM — which built its Enterprise Design Thinking program into a company-wide capability — depends on this property: the stage sequence is teachable to non-designers. The methodology does not require individual creative talent; it requires commitment to a discipline. IDEO U

A stage-ordered process can be adopted across an organization without requiring design backgrounds, and that teachability is the methodology’s genuine strength. Teams can perform the Empathise stage, document conversations with internal stakeholders, and proceed to Define — and they do, reliably, at scale. But here’s the thing. The same quality that lets the process scale also lets the empathy stage get flattened into a workshop activity with no real link to its epistemic function. None of that work generates genuine insight about end users. The stages are necessary conditions; they are not sufficient ones if the substance is replaced by ritual. [Internal link: see Innovation Processes]

Design thinking in action: the IDEO shopping cart

In 1999, ABC Nightline gave IDEO five days to redesign the supermarket shopping cart from scratch. The resulting broadcast — “The Deep Dive” — became the canonical live demonstration of design thinking in practice. What made it instructive was not the cart. It was the sequence.

IDEO’s project team was deliberately cross-functional and deliberately non-specialist. A psychologist. A linguist. A surgeon. Engineers. The composition was intentional. IDEO’s operating premise was that the best innovation outcomes came from teams that were “kind of experts on the process of how you design stuff” rather than domain specialists locked into existing category assumptions.

Day 1 — Empathise in a grocery store

The movement did not begin in a conference room; it began in a supermarket. Team members observed shoppers in context — watching. What they documented: shoppers routinely abandoned carts at basket stands near store entrances because pushing a full cart to retrieve a basket was awkward and time-consuming. Parents managing children while navigating carts were wrestling with a design that treated child safety as a design afterthought. Goods placed flat across the bottom rack were left behind at checkout with enough frequency to be a pattern. None of these observations were novel to anyone who had ever grocery-shopped. All of them were invisible in existing sales and complaint data.

Day 2 — Define: framing the problems that matter

The observation data was synthesized into specific problem statements: safety for children in cart geometry, visibility of items, independence from fixed parking positions near store entrances. Each framing opened the solution space rather than presupposing a category of answer. The discipline of the Define stage is choosing which problems to frame — and recognizing that most organizations, given the same field data, would default to the problem closest to the one already on their roadmap.

Days 3–4 — Ideate and Prototype: foam board and hardware-store parts

The brainstorming session ran under IDEO’s documented rules. “One conversation at a time, stay focused, encourage wild ideas, defer judgment, build on the ideas of others.” Dozens of concepts were generated before any evaluation began. The team then built rough prototypes from materials at hand — foam board, hardware-store wheels, basic welded frames. The prototypes were not presentations. They were physical hypotheses, cheap enough to rebuild and specific enough to test.

Day 5 — Test and present

A working redesign was presented at the end of Day 5. The resulting cart featured modular baskets that could be removed and rolled independently, addressing the parking-lot and in-store navigation problem simultaneously. It also included a child-seat geometry derived from the field observations and a scan-as-you-shop holder that addressed the checkout-abandonment problem. [Internal link: see Human-Centered Design]

What do the numbers say about design thinking?

The business case for design investment is quantitatively supported, but the most frequently cited figures in executive presentations need careful scrutiny before anyone stakes a board decision on them. The credible evidence shows a correlation between strong design practices and financial performance; it does not yet prove that design thinking alone causes it.

The McKinsey figure is the most credible business-outcome correlation available: a large sample, five years, with the report explicitly acknowledging correlation rather than causation. The arxiv finding adds finer-grained academic evidence for a positive effect on creative output, though its sample size is not published in the abstract and the effect is mediated through creative self-efficacy.

The more useful finding is that many teams still skip end-user contact entirely. McKinsey’s study notes that more than 40 percent of surveyed companies still do not talk to end users during development. That finding is arguably more useful for practitioners than the performance premium: it confirms that the user-observation discipline design thinking requires is far from standard, and that the premium — if real — reflects a gap that most organizations have not yet closed. [Internal link: see Innovation Processes]

What is design theater, and why do design thinking programs fail?

“Design theater” describes the performance of design thinking’s five stages without the substance that makes them generative. Teams run empathy workshops with their VP of Sales, brainstorm under convergent pressure, and test prototypes with colleagues who share their assumptions. The output looks like design thinking; the process produces none of its distinctive insight.

Organizations that substitute internal stakeholders for real end users in the Empathise stage are not doing design thinking — they are conducting a facilitated meeting with a branded agenda. The diagnostic is simple: who, specifically, did your team observe? If the answer is anyone who works for your organization, your empathy data is a mirror, not a window.

The user-access substitution failure

The primary failure mode is the substitution of convenient proxies for end users in the Empathise stage. Sales teams. Customer service representatives. Internal product managers. These groups are easy to reach, articulate, and well acquainted with the problem space, and all of them bring organizational filters that distort the insight in patterned ways.

A sales representative describes the complaints they hear most often, namely the ones customers have been willing to escalate to a company representative. An end user in a field observation reveals the workarounds they use silently, the tasks they’ve stopped attempting, and the needs they’ve never articulated because they’ve never been asked. The difference in insight quality is not marginal. Toptal

Toptal’s practitioner survey (2019) identifies this pattern across organizations whose DT programs are failing: “Critics of design thinking believe that it has become yet another corporate box to check off. Once it becomes a ‘Did you remember to check off that box?’ mentality, it is no longer thought-provoking, nor does it stoke the fires of creativity.” The survey documents the pattern widely, though the sample is practitioner self-report rather than a representative prevalence study — the failure mode is documented and common; precisely how common remains unquantified.

The premature convergence failure

The second major failure mode is the organizational efficiency reflex applied to the Ideate stage. An organization optimized for output instinctively wants to rank, filter, and select ideas in real time — which collapses the divergent phase before genuine divergence has occurred. ABC Nightline

The loss is specific: the unexpected ideas — the ones that would not have survived conventional analysis and therefore are not already on the organization’s roadmap — die before they are fully formed. Design thinking’s brainstorming discipline exists to keep those ideas alive long enough to evaluate them after divergence is complete, not during it. When evaluation arrives during generation, the obvious ideas survive and the valuable ones are eliminated by the same organizational assumptions the methodology was designed to challenge.

What design theater actually costs

Design theater produces confident answers to the wrong questions — which is the exact opposite of the intellectual humility that genuine empathy research generates. And confident wrong answers are more dangerous than acknowledged ignorance: they generate investment in solutions that users didn’t need and resistance to revisiting a direction that was never properly validated.

“[Design-thinking] has a really long academic history to it… But over the last years, it’s become this really popular trend to the point where now it’s a buzzword. You’re beginning to see a lot of derailed versions of it … trying to promote the idea that anyone can design. It’s very dangerous to try and universalize many processes and claim it as a single thing.” Natasha Jen

— Natasha Jen, Pentagram partner and design educator, Fortune Brainstorm Design, 2018

Jen’s critique names the organizational dynamic precisely. When a methodology is presented as universally applicable, learnable by anyone and appropriate for every problem, the institutional response is to perform it rather than practice it. Performance satisfies the requirement. Practice generates the insight. These are different outputs. [Internal link: see Human-Centered Design]

How does design thinking differ from agile and lean startup?

Design thinking, agile, and lean startup are not competing methodologies — they address different problems at different phases. Design thinking asks what to build. Agile asks how to build it reliably once the direction is set. Lean startup asks how to test whether the direction is right as cheaply as possible.

When design thinking and agile work together

The two methodologies are complementary because they operate at different phases. Design thinking is strongest at the front end — before a team has committed to a direction and needs to discover what direction is worth committing to. Agile is strongest during delivery — when the direction is set and the question is how to execute reliably with continuous feedback. IDEO U

IBM’s Enterprise Design Thinking program is the most documented live case of integration at scale. The pairing works. IBM adapted the d.school methodology for its enterprise software context, pairing design thinking for problem discovery with agile sprints for delivery. The combination addressed a constraint that pure agile implementations frequently encounter: teams iterating rapidly on a direction that was never validated against genuine user need. Fast iteration toward the wrong answer is not better than slow iteration toward the wrong answer. McKinsey

When lean startup substitutes for design thinking — and when it shouldn’t

Lean startup’s build-measure-learn loop and design thinking’s observe-define-ideate sequence both aim to reduce waste, but they locate waste in different places. Lean startup assumes teams can learn faster from a built minimum viable product than from ethnographic observation. Design thinking assumes that building anything before understanding user behavior carries the risk of iterating on a structurally wrong direction. IDEO U

Lean startup’s MVP is appropriate when the hypothesis is specific enough to test with a lightweight artefact. Design thinking’s Empathise stage is appropriate when the problem itself is unknown or when the existing hypothesis is too broad to test efficiently. Forcing lean startup’s build-first logic onto a poorly-defined problem space generates rapid iteration toward a wrong answer. Forcing design thinking’s ethnographic discipline onto a well-defined hypothesis wastes time. The decision turns on one question: is the problem definition solid, or is that still the thing being discovered?

[Internal link: see Lean Startup, Agile Innovation, Jobs-to-be-Done]

What are the most common misconceptions about design thinking?

Four misconceptions about design thinking are common enough to have driven real program failures — not because they represent misreadings of the academic literature but because they emerge naturally from how the methodology is typically introduced in workshops and executive briefings.

Misconception 1: “Design thinking is a linear five-step checklist.” IDEO U is direct: the sequential presentation is a teaching simplification, not an operating model. Teams that treat Test as a terminal stage — completing it once and proceeding to implementation — have missed the mechanism. The iterative loop is not a flaw to engineer out; it is the process by which design thinking generates learning that a single linear pass cannot produce.

Misconception 2: “Design thinking is only for designers.” The methodology was specifically developed for non-designers. The d.school curriculum has trained nurses, government policy officers, finance executives, and engineers alongside design students — disciplines with no design background and no expectation of developing one. IDEO Design thinking requires willingness to observe users, tolerate ambiguity during ideation, and test rough artefacts. None of those require aesthetic or craft expertise.

Misconception 3: “Design thinking works for any problem.” Don Norman’s “useful myth” critique names this limit directly: the methodology is most valuable when the user need is genuinely unknown. For well-defined problems with known solutions — process optimization, technical integration, standard engineering challenges — design thinking adds ceremony without adding insight. Applied indiscriminately, it wastes time and builds organizational resistance to the methodology in contexts where it would have earned credibility.

Misconception 4: “Design thinking and brainstorming are the same thing.” Ideate is one stage of five. It depends entirely on the quality of the preceding Empathise and Define stages. Brainstorming without prior user observation generates ideas unconstrained by actual user need — which is not the same as divergent thinking grounded in what users experience. ABC Nightline The Ideate stage is what it is because of what precedes it. Isolated brainstorming skips the load-bearing foundation. [Internal link: see Rapid Prototyping]

Where does design thinking break down?

Design thinking is not universally applicable. Healthcare, enterprise software procurement, and well-defined tame problems each present structural constraints that the canonical five-stage framing does not fully address, and applying the full process where it is not needed adds overhead without insight.

Healthcare and regulated environments

Healthcare presents a specific version of the user-access constraint. Patients, in many clinical contexts, cannot be observed in their natural environment. Practical barriers are one reason, and ethical and regulatory restrictions add another. Journey mapping and service design techniques have partially adapted design thinking for healthcare. Healthcare systems run design programs, but these adaptations acknowledge a gap: the methodology was designed for contexts where direct ethnographic observation of end users is routinely possible.

The UK Design Council’s Double Diamond (launched 2004) institutionalized the same diverge-then-converge logic for public-sector contexts. Citizen research reshapes the Empathise stage, and accountability structures and political constraints add further complications.

Enterprise software (B2B)

Consumer product design thinking assumes that the user and the buyer are either effectively the same person or close enough that the user’s experience tilts purchase decisions. Enterprise software violates this assumption structurally. IDEO U

The IT director who approves an enterprise software purchase, the line manager who mandates its use, and the individual contributor who uses it daily have different needs, different definitions of success, and different tolerances for friction. Design thinking’s Empathise stage can observe all three — but its default orientation toward end users structurally underweights buyers and managers, whose veto governs whether the solution ever reaches the users it was designed for. Solutions optimized for end-user experience fail adoption when they don’t address the people who have to approve them. Implementation and enforcement are also overlooked.

Tame problems vs. wicked problems

Horst Rittel and Melvin Webber’s 1973 distinction between tame and wicked problems remains practically useful here. Tame problems have a clear formulation, a stopping rule, and solutions that can be evaluated as right or wrong. Wicked problems strip away all of this: the problem remains only loosely defined until a solution is attempted, each instance is unique, and every solution creates new problems. Don Norman

Design thinking is structurally suited to wicked problems. The iterative loop — from empathy through prototyping and back — is precisely the mechanism for navigating a problem space that resists full specification in advance. Applying that same overhead to tame problems — executing a known process, integrating two defined systems, optimizing a well-understood workflow — adds ceremony without adding value. The methodology’s organizational credibility depends on being honest about which category a given problem belongs to before committing to the full process. [Internal link: see Double Diamond]

Why does design thinking need systems thinking to succeed?

A product that emerges from deep empathy research and careful prototyping can still be absorbed and neutralized by an organization whose incentives and power structures were built to protect the status quo. Design thinking finds what to build. Systems thinking asks whether the organization is structurally capable of building and sustaining it.

What systems thinking contributes

Organizations are systems: they have feedback loops, incentive structures, and emergent behaviors that were designed — or evolved — to optimize for something. That something is frequently not the outcome a design thinking process is trying to achieve. Solutions that challenge the existing system’s optimization run into institutional friction that no amount of good design anticipates. Norman

Teams often describe user-validated solutions being quietly discontinued when their champion leaves, or adopted nominally without the commitment that real implementation requires. Donella Meadows mapped the mechanism in Thinking in Systems: organizations are coherently optimized, and their feedback loops resist changes that threaten the existing arrangement. A formally controlled case study of a DT solution neutralized this way has not been published; the systems-thinking pairing argument is well-grounded in systems theory and practitioner experience, and early experimental research is beginning to validate it.

Don Norman identified this connection directly: “What is design thinking? It means stepping back from the immediate issue and taking a broader look. It requires systems thinking: realizing that any problem is part of a larger whole, and that the solution is likely to require understanding the entire system.”

Applying both in practice

Design thinking produces the user-validated direction while systems thinking maps the organizational constraints the solution will encounter before it is embedded in operations. Doing systems analysis at the end of a design thinking process means constraints appear late, when remediation is pricey. Running it in parallel — identifying the system’s incentive structures and feedback loops while empathy research is still in progress — lets both analyses inform the problem definition before ideation begins.

The compound approach addresses the most common post-DT disappointment: the well-designed solution that was implemented and ignored, adopted without real commitment, or quietly discontinued when its champion left the organization. Understanding the organizational system is not an appendix to the design thinking process. It is the analysis that determines whether the process’s output has a viable path to sustained impact. No amount of good user research changes an organization’s incentive structures. That requires a concurrent analysis, running alongside the design work.

[Internal link: see Systems Thinking]

What does the research actually say about design thinking?

Design thinking’s empirical foundation is thinner than its adoption rate implies. The most frequently cited evidence is case study, practitioner survey, and business correlation data. The picture is getting clearer — but the research base is not yet as strong as advocates typically claim.

The evidence base: what we actually know

The McKinsey Business Value of Design study (2018) is the most rigorous business-outcome correlation available — 300 companies, five years, a multi-factor design index. It finds a meaningful premium for design investment but explicitly acknowledges it cannot establish causation. The most credible reading: design investment changes decision-making behavior. It forces user observation before solution generation, which is the mechanism, and the premium reflects that behavioral shift, not a spurious correlation with firms that happen to be well-managed.

The arxiv 2026 structural-equation study provides finer-grained academic evidence:

“Design Thinking has a significant positive predictive effect on Design Creativity & Innovation (beta = 0.286, p < 0.001).” arXiv

— arxiv.org, Effect of Design Thinking on Creative & Innovation Processes, 2026

The mediation finding matters: the effect runs through psychological mechanisms — creative self-efficacy and collective creative efficacy — not directly through the stages themselves. the 2026 arXiv study This suggests that part of what design thinking does for teams is change how they think about their own creative capacity. The stages may be the delivery vehicle for a confidence effect as much as an evidence-collection one.

The definitional fragmentation problem

A 2013 academic meta-analysis by Johansson-Sköldberg, Woodilla, and Çetinkaya Johansson-Sköldberg et al. identified a core problem: management contexts treat design thinking as the proven path to creative innovation, while design researchers tend to take it for granted or work past it entirely. Same term, different practices — which explains why the literature produces results that resist comparison. The definitional fragmentation is not resolved; it is a standing constraint on what the evidence can actually show.

The practitioner-critic case

The most credible practitioner-critic objections are not about whether design thinking produces value when practiced well. They are about what the methodology loses when it is packaged for mass adoption. Gadi Amit’s critique is the pithiest version:

“Everybody went to some music class when they were four or five, but not everyone is a musician… Can anyone here imagine Mozart not playing the piano? A six week course at Stanford won’t make you a designer.” Gadi Amit

— Gadi Amit, NewDealDesign, Fortune Brainstorm Design, 2018

Amit’s point is about expertise, not methodology. His concern is that by making design thinking teachable to everyone, its advocates have detached it from the craft knowledge and tacit expertise that make design outcomes excellent — reducing a complex discipline to a facilitated process that generates participation but not genuine design competence.

Don Norman’s formulation is different but adjacent: a persistent myth, he argues, holds that designers possess some mystical, creative thought process that places them above all others in their skills at creative, groundbreaking thought. Norman pushes back simultaneously on the mystification of design expertise and the oversimplification of design thinking — which puts him in the unusual position of defending both the critics and the advocates against their strongest versions of themselves.

With real user access and disciplined stage sequencing, design thinking produces measurable improvements in creative outcomes. Practiced as a workshop ritual without genuine user observation, it produces none of those benefits and incurs all of the organizational costs. The two practices share a name. They are not the same thing. [Internal link: see Systems Thinking]

Frequently asked questions about design thinking

What is design thinking in simple terms?

Design thinking is a problem-solving approach that starts by deeply understanding the people affected by a problem before generating and testing solutions. It combines direct observation of users with creative ideation and rapid prototyping in a process any team can learn and apply. The methodology was formalized by IDEO and Tim Brown in Change by Design (2009); its intellectual roots trace to Herbert Simon’s 1969 argument that design is a science of creating preferred states. [Internal link: see Innovation Processes]

What are the five stages of design thinking?

The five stages are Empathise, Define, Ideate, Prototype, and Test. Empathise means directly observing users, Define frames the problem from the user’s perspective in a point-of-view statement, Ideate generates a wide range of solutions with judgment deferred, Prototype builds rough, cheap, testable artefacts, and Test gathers feedback to refine both the solution and the problem definition. The stages are iterative — teams routinely return to earlier stages as testing reveals gaps in their understanding of the problem. IDEO U

Who invented design thinking?

Design thinking as a formal business methodology was shaped by IDEO and codified by CEO Tim Brown in Change by Design (2009). The intellectual foundations trace to Herbert Simon’s The Sciences of the Artificial (1969), which defined design as “a course of action aimed at changing existing situations into preferred ones.” Rolf Faste introduced human-centered design as a formal curriculum at Stanford in the 1980s; David Kelley later co-founded the d.school, which made the methodology widely teachable.

How is design thinking different from traditional product development?

Traditional product development typically begins with a defined product concept or technology and then validates it with the market. Design thinking begins with user observation and works backward to a solution. This sequence reversal makes it more likely to surface genuine unmet needs and less likely to produce solutions in search of problems. McKinsey’s 2018 study found that more than 40 percent of companies still do not talk to end users during development — the default that design thinking inverts.

Is design thinking only for designers?

No. The methodology was deliberately developed as a process for non-designers. The Stanford d.school has trained engineers, nurses, educators, and government officials alongside design students. IDEO U It does not require visual or craft skills. What it requires is the willingness to observe users, tolerate ambiguity during ideation, and test ideas quickly with real people. Gadi Amit’s objection that a six-week course won’t make anyone a designer is about design expertise, not the methodology’s problem-finding framework.

What is the most famous example of design thinking?

IDEO’s 1999 redesign of the supermarket shopping cart was conducted live on ABC Nightline. It remains the most widely cited demonstration. In five days, a cross-functional team observed shoppers in context, identified unmet needs around child safety and awkward item handling, generated dozens of concepts, built rough prototypes, and produced a working redesign. The project illustrated all five stages in compressed real time and became the canonical teaching case because it made the methodology visible.

What is the difference between design thinking and agile?

Design thinking focuses on discovering what to build by understanding users before committing to a solution direction. Agile focuses on how to build efficiently once that direction is set — through iterative delivery, continuous stakeholder feedback, and flexible scope management. The two are complementary; many organizations use design thinking at the front end of discovery and agile methods during development and delivery. IBM’s Enterprise Design Thinking program is the most documented case of combining them at scale. McKinsey

Contributor

Clara @cla_reinholt

Focuses on innovation communication, facilitation, and turning frameworks into team habits.

Clara writes about the human systems behind innovation: facilitation quality, communication clarity, and the routines that help teams move from ideas to decisions. She follows practical team-method sources such as the Atlassian Team Playbook, alongside innovation coverage from McKinsey and Harvard Business Review.

Her contributions often combine editorial storytelling with practical templates that leaders can reuse for team rituals, retrospectives, and portfolio reviews, informed by research and practices from McKinsey on Innovation, Harvard Business Review, and the Atlassian Team Playbook.

Clara tends to ask one recurring question in her drafts: Will this help someone lead a better conversation tomorrow? If the answer is yes, the piece is ready.