Design as Thinking Tool

There’s a persistent misunderstanding about what designers do. The popular version goes something like this: engineers solve the hard problems, product managers decide what to build, and designers make it look nice. Colors, fonts, spacing, rounded corners. The decorative layer.

This is wrong in a way that matters. Design isn’t decoration. Design is a way of thinking about problems. A specific, disciplined, learnable way of thinking that produces different outcomes than analytical thinking, and that is valuable precisely in the situations where analytical thinking gets stuck.

I want to make this argument carefully, because the “design thinking” brand has been so thoroughly commodified and diluted that many smart people now dismiss the idea entirely. They’ve sat through too many Post-it workshops that produced nothing. They’ve watched too many consultancies charge six figures for empathy maps that told them what they already knew. The backlash is understandable.

But the backlash throws out something real: the cognitive approach that designers use when they’re actually designing (not facilitating workshops) is genuinely different from, and complementary to, the cognitive approaches used by engineers and analysts. Understanding what that difference is, and when it’s useful, is worth the effort.

Schon’s reflective practitioner

The best articulation of how designers actually think comes not from the design thinking movement but from Donald Schon, an MIT professor who spent his career studying how professionals in complex fields (architecture, medicine, law, engineering) actually solve problems in practice, as opposed to how textbooks say they should solve them.

Schon’s key book, The Reflective Practitioner (1983), makes a simple but profound argument: the way skilled practitioners solve problems is fundamentally different from the technical rationality model taught in universities.

Technical rationality says: define the problem clearly, identify the relevant theory, apply the theory to derive a solution. It’s the scientific method applied to professional work. And Schon observed that it almost never describes what practitioners actually do.

What practitioners actually do, Schon found, is engage in what he called “reflection-in-action”: a process of making moves, observing the results, and adjusting based on what the situation “says back.” The practitioner doesn’t separate thinking from doing. They think through doing. Each action is simultaneously a probe, a test, and a means of reshaping their understanding of the problem.

He described this as a “conversation with the situation.” The designer makes a move (a sketch, a prototype, a structural decision). The situation responds (the sketch reveals a spatial conflict, the prototype exposes a workflow problem, the structure creates an unintended dependency). The designer responds to the response. The conversation continues until the situation “makes sense” to the practitioner.

This is not trial and error. It’s more precise than that. Each move is informed by accumulated professional judgment, and each response is interpreted through deep domain knowledge. A skilled architect doesn’t randomly try layouts. They make moves based on years of experience with spatial relationships, light, circulation patterns, and structural constraints. But they also don’t plan the entire building before making the first move. They think through making.

The implication for product people is direct: some problems can’t be solved by analyzing them from the outside. They can only be solved by engaging with them, making concrete moves, and learning from what happens. This is the core of design as thinking.

Three kinds of reasoning, and why the third one matters

To understand what makes design thinking distinct, it helps to compare three types of reasoning.

Type	Logic	Movement	Example
Deductive	General rule + specific case = conclusion	From theory to prediction	“All metals expand when heated. This is metal. Therefore it will expand.”
Inductive	Specific observations = general pattern	From data to theory	“Every user I’ve observed clicks the back button here. This flow is probably confusing.”
Abductive	Surprising observation + imagination = best explanation or hypothesis	From observation to creative leap	“Users are abandoning the checkout. Maybe the problem isn’t the form; maybe they’re not confident in the product yet.”

Deductive reasoning is the backbone of engineering and mathematics. You start with established principles and derive correct conclusions. It’s powerful and reliable in well-defined domains.

Inductive reasoning is the backbone of data science and empirical research. You observe patterns in data and generalize to broader conclusions. It’s powerful when you have enough data and the patterns are stable.

Abductive reasoning is what designers rely on most heavily, even if they don’t use that term. Jon Kolko, who has written extensively about design cognition, describes abductive reasoning as “the creation of new knowledge and insight, introducing a best guess for why something is occurring, even if it’s not part of the original set of premises.”

Abductive reasoning doesn’t prove anything. It generates hypotheses. It takes incomplete information, combines it with experience and imagination, and produces a plausible explanation or solution that can then be tested. It’s the cognitive move that produces the “what if” moment: what if the problem isn’t what we think it is? What if the solution looks completely different from what we expected?

This is why designers are valuable in ambiguous situations where engineers and analysts get stuck. Engineers excel when the problem is well-defined. Analysts excel when the data is available. Designers excel when neither condition holds, when the problem itself needs to be reframed before it can be solved.

Problem setting vs. problem solving

This brings us to Schon’s most important insight: in complex professional practice, the hardest part isn’t solving the problem. It’s setting the problem. Figuring out what problem you’re actually trying to solve.

Most organizations assume the problem is given. “Users are churning.” “Revenue is flat.” “The onboarding flow is too long.” These sound like problem statements, but they’re actually symptoms. The problem behind the problem might be something entirely different.

Users are churning… because the product doesn’t deliver value until week 3, and they give up in week 1. Revenue is flat… because the pricing model doesn’t match how customers derive value. The onboarding flow is too long… because the product’s core concept is too complicated, and no amount of onboarding will fix that.

Design thinking, in its original and most useful sense, is the practice of problem setting: stepping back from the presented problem, examining it from multiple angles, reframing it, and arriving at a problem statement that, when solved, actually produces the desired outcome.

This is hard to do well. Most people, when presented with a problem, immediately start generating solutions. It feels productive. It feels like progress. The discipline of staying in the problem space, resisting premature solution generation, and exploring different framings of the problem requires genuine cognitive effort and organizational trust.

Here’s a concrete example from my experience. A team was asked to “improve the dashboard.” The dashboard was information-dense, hard to read, and users complained about it. The obvious solution was to redesign the dashboard: better layout, clearer visualizations, less clutter.

The designer on the team pushed back. Before redesigning the dashboard, they spent a week watching users interact with it. What they discovered: users weren’t looking at the dashboard for information. They were looking at it for reassurance. They wanted to know that nothing was broken. The detailed data wasn’t what they needed. They needed a simple signal: everything is fine, or something needs your attention.

The reframing shifted the solution from “redesign the dashboard” to “build a status indicator that tells users whether they need to take action.” The resulting product was dramatically simpler than a redesigned dashboard. Satisfaction scores went up. Time-on-dashboard went down (which was a good thing, because users no longer needed to scan dense charts to get their answer).

That reframing is design as thinking. The designer didn’t make the dashboard prettier. They questioned whether a dashboard was the right solution at all.

Design thinking: the movement, and its problems

I need to address the elephant in the room. The “design thinking” movement, as popularized by IDEO, Stanford’s d.school, and a thousand corporate innovation programs, has taken the genuine cognitive practices I’ve described above and packaged them into a five-step process: Empathize, Define, Ideate, Prototype, Test.

This process isn’t wrong. Each step captures something real about how good design happens. The problem is what happened when this process was sold as a universal innovation methodology to organizations that didn’t have designers, didn’t understand design, and wanted a recipe for creativity.

The result, as critic Lee Vinsel has argued, was widespread “innovation theater”: workshops full of Post-its and empathy maps that produce excitement but not outcomes. Jake Knapp, who ran design thinking workshops at Google before creating the design sprint methodology, observed the same thing: the brainstorming sessions generated enthusiasm and sticky notes, but they rarely led to built products.

The specific criticisms of institutionalized design thinking that I find most compelling:

Criticism	What it means	Why it’s valid
Innovation theater	Checking boxes without implementing meaningful change	Many organizations treat the workshops as the output, not the prototype
Narrow solution space	The process preordains that the answer is a product or service	Some problems need systemic, policy, or organizational solutions
Naive empathy	One-day empathy exercises trivialize the depth of user understanding	Real empathy takes sustained engagement, not a Post-it exercise
Lack of follow-through	Ideas generated but never implemented	Without connection to engineering and business constraints, ideas stay on whiteboards
Theoretical thinness	Practical method without rigorous academic foundation	The process was derived from practice observation, not tested theory

These criticisms are valid. And they don’t invalidate the underlying cognitive practices. Schon’s reflective practice, abductive reasoning, problem setting, prototyping as thinking: these are real, valuable cognitive tools. The failure was in packaging them as a paint-by-numbers process that anyone could follow regardless of skill or context.

Prototyping as thinking

Of all the practices within design cognition, prototyping is the one that has the broadest application outside traditional design disciplines. And it’s the most misunderstood.

Most people think of prototyping as “building a rough version of the solution to test whether it works.” That’s part of it. But the deeper function of prototyping is thinking through making. The prototype isn’t just a test artifact. It’s a thinking tool.

When you prototype, you’re forced to make decisions you can defer in an abstract discussion. A specification can say “the user selects their preferences.” A prototype has to show how. Checkboxes? Sliders? A conversational wizard? Each choice reveals different trade-offs that were invisible in the abstract description.

The act of making the prototype exposes:

- Assumptions you didn't know you were making
- Conflicts between requirements that seemed compatible on paper
- Edge cases that only appear when you try to build the thing
- Emotional reactions that can't be predicted from specifications
- Dependencies between features that aren't visible in roadmaps

This is why the old design maxim “show, don’t tell” is more than a communication strategy. It’s a cognitive strategy. You understand the problem better after you’ve tried to solve it, even if your first attempt is terrible. The attempt is the thinking.

Bill Buxton, the interaction design researcher, makes a useful distinction between prototyping and building. Prototyping is building something to learn. Building is building something to ship. The fidelity, the materials, the engineering standards are all different because the purpose is different. A prototype’s job is to answer a question, not to be a product. If you’re not learning from the prototype, you’re just building slowly.

Fidelity levels as cognitive tools

Different fidelity levels serve different thinking purposes:

Fidelity	What it looks like	What it tests	When to use it
Paper/sketch	Hand-drawn screens, sticky note flows	Concept viability, information hierarchy	Very early exploration, problem reframing
Wireframe	Grayscale layouts, placeholder content	Structure, flow, content hierarchy	After concept is validated, before visual design
Clickable prototype	Interactive mockup (Figma, Framer)	User comprehension, task flow, interaction patterns	Usability testing, stakeholder alignment
Functional prototype	Real code, limited scope	Technical feasibility, performance, integration	Engineering validation, late-stage testing

The mistake I see most often: teams jumping to clickable prototypes before they’ve done the thinking that paper prototypes enable. A Figma prototype takes days. A paper prototype takes minutes. And for many questions (Is this the right structure? Does this flow make sense? Are we solving the right problem?), the paper prototype gives you the answer faster, cheaper, and with less commitment to a specific solution direction.

The paradox of constraints

One of the counterintuitive principles of design thinking is that constraints enhance creativity rather than limiting it. This sounds like a motivational poster platitude, but there’s real cognitive science behind it.

Unconstrained problems are paralyzing. “Design something cool” produces blank stares. “Design a way for a blind person to order coffee in a noisy cafe” produces immediate engagement. The constraints define the problem space, and the defined problem space gives the designer something to push against.

Charles Eames captured this: “Design depends largely on constraints.” And Igor Stravinsky, in a different domain: “The more constraints one imposes, the more one frees oneself of the chains that shackle the spirit.”

In product design, constraints come from multiple sources:

Technical:   What the platform can do. Performance limits.
             API capabilities. Device constraints.

Business:    Budget. Timeline. Revenue model. Market positioning.
             Regulatory requirements.

User:        Mental models. Ability levels. Context of use.
             Attention span. Emotional state.

Design:      Brand guidelines. Accessibility requirements.
             Consistency with existing product. Platform conventions.

The designer’s job is not to eliminate constraints. It’s to find creative solutions within them. The most elegant designs are often the ones that satisfy the most constraints simultaneously with the simplest solution.

Twitter’s original 140-character limit is a perfect example. The constraint (imposed by SMS limitations) forced a specific kind of communication: short, punchy, public. That constraint didn’t limit Twitter. It defined Twitter. Without it, Twitter would have been a less interesting version of every other social platform.

The product implication: when defining a design problem, don’t try to remove all constraints first. Add them. The constraints are what make the problem solvable and the solution interesting.

Design beyond products

The design thinking approach (the real one, not the workshopped version) applies beyond product design. Wherever you face ambiguous, ill-defined problems that resist analytical approaches, design cognition is useful.

Organizational design. How should teams be structured? What should the communication patterns be? How should decision rights be distributed? These are design problems: ill-defined, multi-stakeholder, with no single correct answer. Prototyping (trying a team structure for a quarter and iterating) is more effective than analyzing the optimal structure from first principles.

Strategy. “What business should we be in?” is a design problem, not an analytics problem. It requires problem reframing (are we a software company or a data company?), abductive reasoning (what if the market shifts this way?), and prototyping (small experiments to test strategic hypotheses).

Process design. How should we review code? How should we run retrospectives? How should we handle on-call rotations? These are design problems with the same properties: multiple stakeholders, competing constraints, no single correct answer, and an environment that changes.

The common thread: design thinking is most valuable when the problem is “wicked” (Horst Rittel’s term): where the problem definition is itself contested, where there are many stakeholders with different values, where the solution to one problem creates new problems, and where there’s no definitive test of correctness.

Rittel identified ten properties of wicked problems. The first two are the most important for product people:

1. There is no definitive formulation of a wicked problem
2. Wicked problems have no stopping rule (you can always do more)

Most interesting product problems are wicked. “Make the product more engaging” has no definitive formulation and no stopping point. Design thinking provides a way to make progress on wicked problems without pretending they can be definitively solved.

The designerly way of knowing

Nigel Cross, a British design researcher, coined the term “designerly ways of knowing” to describe the epistemic practices specific to design. His argument: design knowledge is different from scientific knowledge and humanities knowledge. It’s a third kind of knowing, rooted in practice rather than theory, in synthesis rather than analysis, in the artificial (human-made) rather than the natural.

The comparison is useful:

	Science	Humanities	Design
Method	Controlled experiment	Analogy, metaphor, criticism	Modeling, prototyping, synthesis
Values	Objectivity, rationality	Subjectivity, justice, imagination	Practicality, appropriateness, ingenuity
What it produces	Knowledge of the natural world	Knowledge of human experience	Working artifacts that serve purposes
Success criteria	Truth, predictive power	Insight, empathy	Utility, fitness, delight

Cross’s point is not that design is better than science or humanities. It’s that design is different, and that the difference matters. An organization that thinks only in scientific terms (hypothesis testing, data analysis, statistical significance) and humanities terms (narrative, empathy, meaning) but lacks design thinking (prototyping, synthesis, making) is missing a cognitive mode that’s essential for creating things that work.

Practical applications for product teams

If I’m being practical (which I should be, since most people reading this are building products), here’s how I think about applying design cognition within a product development process.

Use prototyping as your primary thinking tool

Don’t discuss solutions in the abstract. Make them concrete. Even rough, ugly prototypes generate better conversations and faster decisions than slide decks and specifications. The prototype forces decisions that discussions defer.

Practice problem reframing

Before you accept the problem statement you’ve been given, ask: “Is this the right problem?” Spend at least 20% of your time in the problem space before moving to solutions. Watch users. Ask why things are the way they are. Look for the problem behind the problem.

Embrace constraints explicitly

When starting a design problem, list all known constraints. Don’t fight them. Use them as creative scaffolding. The more precisely you can articulate the constraints, the more focused and creative the solution space becomes.

Think in systems, not screens

A screen is an interface to a system. Design the system first: the conceptual model, the object relationships, the state transitions, the rules. Then design the screens as windows into that system. Products designed screen-by-screen feel fragmented. Products designed as coherent systems feel unified.

Build the reflective practice loop

After every major design decision, take five minutes for structured reflection:

What did I expect to happen?
What actually happened?
What does the gap tell me about my assumptions?
What would I do differently next time?

This is Schon’s reflection-on-action, and it’s how design judgment develops over time. The loop is simple. The discipline of actually doing it, consistently, is what separates designers who improve from designers who repeat.

The anti-decoration manifesto

I started this post by pushing back on the idea that design is decoration. Let me end by being specific about what I mean.

Decoration is about surfaces. Design is about structures.

Decoration asks: “How should this look?” Design asks: “How should this work?”

Decoration can be done after the decisions are made. Design is the decision-making process.

Decoration is a skill. Design is a way of thinking.

When organizations relegate designers to the decoration role (hand them specifications and ask them to make it look good), they lose access to the cognitive tools that designers bring: problem reframing, abductive reasoning, prototyping as thinking, synthesis across constraints. These tools are most valuable at the beginning of the process, when the problem is being defined and the solution space is being explored, not at the end, when the decisions are made and only the surface remains.

The organizations that get the most value from design are the ones that involve designers at the problem-setting stage, not just the problem-solving stage. That’s where design thinking, the real kind, does its best work.

Design is not making things pretty. It’s making things make sense. And making things make sense is harder, more valuable, and more interesting than making things pretty could ever be.