What Is Design Thinking? Modes, Origins and Evidence

Created by Herbert A. Simon, with later development and popularization by IDEO and Stanford d.school - https://en.wikipedia.org/wiki/Herbert_A._Simon

Overview

Design Thinking is a human-centered, collaborative and iterative way of working on complex problems, using the methods designers use to understand people and shape solutions. IDEO states plainly that there is no one definition of design thinking and describes it as a set of mindsets and design-based activities that foster the collaboration needed to solve problems in human-centered ways. The most quoted version comes from IDEO's Tim Brown, who calls it a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success. IDEO compresses that into three tests a solution must pass: desirable for people, feasible with technology and viable for the organization.

The method has no single inventor. Herbert A. Simon was the first to mention design as a way of thinking in his 1969 book, The Sciences of the Artificial, and through the 1970s he contributed ideas now regarded as principles of design thinking. A review of early design research places Simon's book alongside other foundational works in design methodology and notes that Simon's approach sought to formalize design through engineering, rational problem-solving and human psychology. Simon's definition, "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones," treated design as any intentional change, not just the making of objects. The contemporary version moved that theory into practice. Tim Brown's Change by Design presented design thinking to business readers as a collaborative process for matching people's needs with what is technically feasible and a viable business strategy, and a CCA conversation about the book sums up its inspiration, ideation and implementation cycle.

Stanford's d.school gave the method its best-known classroom shape. The d.school identifies five modes: Empathize, Define, Ideate, Prototype and Test. In Empathize, the team studies the people affected, and the d.school's bootleg deck calls empathy the foundation of human-centered design because the problems you solve are rarely your own. Define synthesizes that research into a clear problem. Ideate goes wide on radical alternatives. Prototype makes ideas tangible, from an object to a role-play, and Test puts prototypes in front of users to refine both the solution and the team's grasp of the problem. The modes are not a checklist. The d.school itself argues against talking about THE design process, noting that intro workshops rush a linear five-step sequence in about 90 minutes, and IxDF describes the phases as non-linear and iterative.

flowchart LR
  E[Empathize] --> D[Define]
  D --> I[Ideate]
  I --> P[Prototype]
  P --> T[Test]
  T -->|reframe problem| D
  T -->|new ideas| I
  T -->|learn more| E

The closest alternative is the UK Design Council's Double Diamond. Its history describes four phases, Discover, Define, Develop and Deliver, chosen as a deliberately memorable device. The Design Council's framework treats each diamond as divergent exploration followed by convergent action, and its first diamond exists to help people understand, rather than simply assume, what the problem is. The two map closely: Discover and Define cover Empathize and Define, Develop covers Ideate, Prototype and Test, and Deliver covers the implementation that the d.school modes leave implicit. Reach for the Double Diamond when stakeholders need the diverge and converge rhythm made explicit, and for the d.school modes when a team needs named activities it can practice.

The evidence is real but uneven. Most studies measure short-term, perceived or educational outcomes rather than market results.

Read these figures carefully. The organizational study asked respondents about perceived impact, so its percentages are self-reports, not controlled comparisons, and the engineering review (source) examined differing implementation strategies and core elements, which makes studies hard to compare. The sources establish no accepted success rate against Agile, Lean Startup or traditional R&D, so treat any such headline with suspicion. The same discipline belongs inside a project: the d.school describes synthesis as frameworks, maps and abductive thinking, so keep observed behavior in the research record and hold explanations of why it happened as interpretations still to test. Hamster Studio teams can keep research notes, insights and test results side by side in one shared workspace so that line stays visible.

Core Principles

Start with the people who have the problem

The team's own assumptions are the least reliable input, because the problems you are solving are rarely your own. Research means observing and talking with the people affected, in their context, before proposing anything. If the first artifact a team produces is a solution sketch rather than notes about users, this principle has been skipped.

Pass all three tests, not just one

A good solution is desirable for people, feasible with technology and viable for the organization. Users loving a concept does not make it buildable or sustainable, and a profitable idea nobody wants fails too. Evaluate candidates against all three lenses together so trade-offs surface early instead of at launch.

Reframe the problem before solving it

The Define mode exists because the first statement of a problem is usually a symptom or a disguised solution. A 2025 review of 69 articles names reframing as one of four mechanisms through which the method may create impact. A useful frame names a specific user, a need and an insight that shifts the team's perspective.

Diverge before you converge

Generating options and choosing between them are different activities, and separating idea generation from idea selection strengthens both. Judging ideas as they appear kills the unusual ones that often lead somewhere. Hold a clear boundary between the wide phase and the narrowing phase, and announce when you cross it.

Make ideas tangible early

A prototype turns an argument into something people can react to, and the d.school counts a role-play or an object as a prototype alongside more familiar forms. Rough and cheap is the point, because it keeps the team willing to throw weak ideas away. When a team spends weeks polishing before anyone outside sees it, learning has stalled.

Move between modes as evidence demands

The d.school cautions against treating design as one fixed process, and IxDF calls the phases non-linear and iterative. A failed test might send you back to Define because the problem was wrong, or to Empathize because you misread users. Running the five modes once, in order, and calling it done is the most common way the method degrades into theater.

Keep evidence separate from interpretation

Synthesis relies on frameworks, maps and abductive thinking, which means reasoning to the most plausible explanation. That explanation is a hypothesis, not a finding. Record what people did and said apart from why you think they did it, so later tests can confirm or overturn the interpretation.

Steps

1. Empathize with the people affected Observe and interview the people who experience the problem, ideally in the setting where it happens. Capture quotes, behaviors, workarounds and emotional moments rather than feature requests. Include people at the edges, not just typical users, because extremes reveal needs the average hides. The output is a research record of what you saw and heard.

   If your notes are mostly opinions about what users should want, go back into the field.

2. Synthesize and define the problem Cluster observations into patterns, then interpret those patterns into insights about needs, as covered in synthesizing user insights. Choose the insight that most shifts the team's perspective and write a point-of-view statement naming a specific user, their need and that insight; see framing human-centered problems. Turn the statement into a focused prompt such as a How Might We question. The frame is wrong if it smuggles in a solution or describes a generic customer.

3. Ideate widely Run a time-boxed session that aims for many varied ideas and defers judgment, following the practices in generating divergent ideas. Invite people from different functions and look for inspiration from other domains. Capture every idea visibly, including the absurd ones. Only after generation stops should the group select a handful of promising directions to prototype.

4. Prototype cheaply Turn the selected ideas into rough artifacts that someone else can use or react to: paper screens, a storyboard, a role-played service, a cardboard object. Build only what the question you are testing requires, as described in building rapid prototypes. Make more than one version where you can, so users compare rather than just approve. If building takes longer than testing, you are over-investing.

5. Test with real users Put the prototype in users' hands, or put users in the prototype, and give only the context they need to start. Watch what they do before asking what they think, because behavior is more reliable than stated preference. Record what worked, what confused people and what surprised the team. Evaluate surviving concepts against desirability, feasibility and viability together, using balancing desirability, feasibility, and viability.

6. Loop back or move to implementation Decide from the test evidence where to go next: refine the prototype, generate new ideas, reframe the problem or return to research. Iterating from evidence covers how to make that call deliberately. When a concept has passed tests on all three lenses, turn it into a concrete plan with an owner, scope and timeline. A cycle that ends in a presentation with no owner has not finished.

When to Use

• The problem is ill-defined or contested, because the method is built to challenge assumptions and redefine the problem before committing to a solution.
• You are designing a new product, service or experience for people whose lives and constraints the team does not share, so direct research will correct blind spots.
• Several functions (design, engineering, business) must agree on a direction, because the desirability, feasibility and viability lenses give them a shared vocabulary for trade-offs.
• Early concepts can be tested cheaply with paper, role-play or mockups before significant investment, which lets you learn fast and discard bad ideas.
• A team keeps shipping features that users ignore, a sign that the problem framing rather than the execution is failing.

When Not to Use

• The problem is well-understood and the solution is known, such as a routine compliance update, where research and ideation add cost without changing the answer.
• An emergency requires immediate action, because the method's research and iteration loops assume time to learn before committing.
• You have no access to real users and no way to get it, since empathy and testing are the core inputs and substituting team opinion defeats the purpose.
• Nobody owns implementation after the workshop, since only 12% of surveyed teams reliably ship what their design sessions produce and without an owner the output becomes a wall of sticky notes.