Sep 8, 2025
Design thinking vs Computational thinking
Design Thinking vs Computational Thinking: Explore how these approaches influence product design, problem framing, and solution strategies.
Author
Daryna RajkumariUI & UX Designer
Book a call
Table of Contents
Design Thinking vs Computational Thinking in Product Design
A dual process model for addressing digital design problems — Drawing on examples from architectural design philosophies
Introduction
Design thinking is commonly referred to in the literature on design as a non-linear, iterative process that teams use to understand and define problems. A second type of ‘thinking’, known as computational thinking, is solving problems, designing and understanding systems, by drawing on the concepts fundamental to computer science. In this article, I want to show the similarities and differences of these two different modes of thinking, and how modern designers utilize it in solving everyday design problems.
Design thinking
The term design thinking has been overused and yet it remains vague as a term. It originates from scientific research into design cognition and design practice. Design thinking is the body of knowledge that has been accumulated about how individuals think when they work on design issues.
Design problems are those problems that are goal-directed and constrained problems, that rely on a designer’s interpretation of context. They can be differentiated from non-goal-directed and bounded problems (e.g., artistic problems), as well as from problems where all the variables are known beforehand (e.g., engineering optimization or mathematical problems).
Design thinking is most useful to tackle ill-defined or unknown problems. It is the understanding built up about how individuals think when confronted with ambiguous issues, where thinking happens within a specific context.
The essence of design thinking is the insight that a designer constructs (a frame), in which design activity takes place. This notion of an insight as a frame has several sources. One is in situated cognition, where knowledge is conceived as situated in (or within) the frame, in which it is being used and learned. Another is in artificial intelligence, where frames are used to outline top-level organization of knowledge. A third is in sociology, where frames are characterized as constructions that people employ to organize experience. The shared theme is that a designer’s knowledge does not reside in abstract pieces of information, but is employed to build up a rich store of knowledge assemblage — the frame — when presented with a design problem. Bear with me, let me elaborate.
Designers gain much of their insight from framing problems and switching frames. They usually have an idea of problem space and solution space and develop these in tandem as they design. This leads to discoveries or rare insights that alter the course of the design process using these frames.
It implies that a design problem can be thought about very differently by the same person at different times. Problems amenable to design thinking are those where there isn’t an obvious solution: the space for solutions needs to be developed. For instance, problems like those in social planning (e.g. event planning), contain hidden variables and incomplete knowledge, and call for design thinking. Experts in framing possess metacognitive abilities to monitor their frame and discover means of widening it towards useful solutions.
Most examples of great design demonstrate remarkable ability at framing. In architecture, Jørn Utzon’s Sydney Opera House design, for example, defied competition rules by expanding the frame of the problem to accommodate his vision.
In Utzon’s own words “The real challenge here isn’t just to make a good performance hall — it’s to create a piece of architecture that defines Sydney for generations.”
Similarly, Frank Lloyd Wright’s Falling water presented innovative concepts by framing the design to extend the landscape context, even going against the client’s demands.
In design school, students learn to think about the user, the situation or location, and research. These tactics indirectly alter the frame in productive ways. The result of the design process is documentation or representation of the solution. Design solutions, importantly, are often specific to their problem. For instance, an architectural design adapts to its particular site and occupants; the same design in another location typically results in suboptimal performance. Similarly in digital products, design solution specificity is prevalent across all design fields.
Computational thinking
One of the influential definitions defines computational thinking as a matter of solving problems, designing systems, and understanding human behavior in terms of ideas central to the field of computer science. Another defines it as the mental processes involved in problem and solution formulation so that the solutions are cast in a form executable by an information-processing entity (human or computer). We look at the cognitive indicators of computational thinking and the nature of the solutions that it yields. Computational thinking is not human thinking like computers; it is the problem-solving strategies that computer scientists and engineers employ.
The fundamental cognition in computational thinking is abstraction — going from concrete instances to abstract patterns by retaining pertinent information and eliminating irrelevant details.
Abstraction is one of the main cornerstones of computational thinking. By abstraction, individuals find patterns in intricate systems. One famous example is toasting bread: by dividing the process into steps (an algorithm), one observes which steps are critical (such as putting the bread into the toaster) and which minutiae are irrelevant (such as how the hand is moved to put the bread in). One of the fundamental abilities of computational thinking is selecting the appropriate abstraction.
Computational thinking problems are normally well-structured or defined in such a way that there is a need for a well-structured solution (an algorithm). They tend to be repeated problems that happen frequently. Computational thinking involves solving problems in a way that applies to many similar problems, often using computers, so solutions can be reused in other contexts. For example, city navigation is solvable by software such as Google Maps; the same solution applied after solving can be implemented on any city by varying the data, not the algorithm.
Design thinking and computational thinking
In spite of the usage of both terms being very popular, very little in literature contrasts design thinking and computational thinking to discuss their relationship — perhaps because there is no agreement on their definitions. While researching for this article, I came across just one published article co-relating the two types of thinking. Design thinking and computational thinking can be viewed as archetypes in a range of approaches. A thinker will drift across this range within one problem.
In my experiment, I gave the same problem “how would you approach the problem — making a Google Docs for blind users” with two different groups. The first was a group of designers and the other, a group of developers. The developers started by asking “will it be an app or a website?”, “we will probably have to give a voice assistant”, “proper semantics for HTML”, “ARIA labels, ARIA region, proper ALT tags” and much more. Whereas the designers asked more general questions like “How do blind users understand “collaboration” in a shared document?”.
Some activities concentrate nearly exclusively on design thinking (e.g., engineering design of a machine) with minimal computational thinking; others concentrate on computational thinking (e.g., sorting a list) with minimal design thinking. Some activities have both, e.g., a web designer answering a client’s brief. All these activities have a thinker, a design problem, and a solution. We recognize two variables to distinguish design thinking and computational thinking: (1) the generality/specificity of solutions and (2) the generality/specificity of the frame.
4.1. Specificity of solutions
Design thinking and computational thinking generate solutions at opposite ends of a continuum. A common design solution is very specific to the problem — fitted to the users, context, situation, etc. It is seldom that a design solution for one problem can be directly applied to another problem without some further design effort to fit it. Computational solutions, on the other hand, tend to be applicable to new problems with no need for change. For many researchers, that is the hallmark of computational thinking.
Therefore, one dimension is the specificity of the solution to the initial problem. In design thinking, solutions seek to address the specific problem with minimal consideration for reusing them later. In computational thinking, solutions seek to be more generic than the problem being addressed
The extremes: thinking is maximally specific when the thinker is concerned with only the problem at hand, without reuse. Thinking is maximally general when the thinker is concerned with using their reasoning at a higher level of generality. Thinkers are not fixed at extremes; instead, all problem solving is along this continuum, and a thinker can traverse it during problem solving.
4.2. Specificity of framing
The second variable has to do with how the thinker defines the problem. Design thinking, for instance, has activities such as user research, material exploration, and reading theory that widen the frame of knowledge around the problem. Good design frequently adds cultural elements to the frame, for instance. Computational thinking, on the other hand, keeps the essential relationships in mind and discards the larger context (for instance, cultural minutiae are typically abstracted away).
Thus, another type is how general or specific the frame is. A thinker can move their frame to more general or more specific while solving problems. The implication is that design thinking has a tendency to generalize the frame, though a designer will sometimes employ an instance of a frame as part of the process.
On one end, thinking is about constricting the frame: deleting variables and diminishing ambiguity. On the opposite end, thinking is about broadening the frame: introducing variables and heightening ambiguity. Thinkers travel along this continuum throughout a problem.
4.3. An ontology for reasoning about problems
The frame specificity and solution specificity categories are orthogonal to each other. This forms a two-dimensional space — an ontology — for the way that humans think about problems with design thinking or computational thinking. It establishes axes (frame specificity, solution specificity) to depict the way that humans think about problems.
Within the space spanned by these axes, the upper-left quadrant corresponds to the description of design thinking: the thinker is looking for an extremely particular solution while getting an overall sense of the problem and situation. The lower-right quadrant corresponds to computational thinking: the thinker generates general solutions by developing a specific sense of the problem through abstraction.
Discussion and conclusions
Utility of the ontology
The usefulness of the ontology is apparent in examples. Suppose a web designer is working on a client’s brief. First, the designer invests hours finding out about the client’s requirements and browsing other websites. This is in the upper-left quadrant (design thinking): widening the problem space by acquiring knowledge of the client and context, with the goal of a single solution. Subsequently, the designer may employ a spreadsheet to produce code — a computational thinking act (bottom-right quadrant) since the spreadsheet (an abstraction) can be reused across other projects.
Let us take an example from engineering. After attempting to grasp the problem, an engineer develops a parametric model for generating solutions. Developing the parametric model involves computational thinking (determining the appropriate abstraction for an algorithm). The output of the model then drives subsequent design thinking about user requirements. A designer may also create a component-driven design (computational thinking) and then apply it to discover a solution (design thinking).
This is referred to as epistemic fluency — being flexible and proficient with different forms of knowing. It implies fluency between design thinking and computational thinking to be an essential skill.
Both concepts are essential, but they are commonly taught in isolation. Since they are complementary, it might be an advantage to learn them in a manner stressing their interconnectedness.
Are design patterns design thinking or computational thinking?
Design patterns codify the essence of a solution at an abstraction level for reuse. Each pattern outlines a common problem and its essential solution so that it can be reused numerous times. Since design patterns are about making abstractions, are they design thinking or computational thinking? The answer is that they are utilized during design thinking, but developed with the application of computational thinking.
Designers apply design patterns to move their problem frame towards beneficial solutions (design thinking, top-left quadrant). By contrast, to develop a design pattern is computational thinking (bottom-right quadrant): it takes the appropriate abstraction to identify a general solution that can be used “a million times over.”
What’s in the top-right and bottom-left quadrants?
The ontology has a quad in the upper-right and lower-left which is not used. What are those quadrants for? Are they never utilized? Let’s discuss:
The upper-right quadrant (general solution, widening frame) could be said to describe academic theory development, but has nothing to do with design problem solving. Thinking that this applies to may not resolve to a solution in the design setting.
The lower-left quadrant (specific solution, decreasing frame) could be said to describe solving a mathematical equation under particular constraints, which again has nothing to do with design problem solving.
A dual process model of design thinking and computational thinking?
So, the ontology implies design thinking (upper-left) and computational thinking (lower-right) as two different modes people use to reason about everyday problems. This is a dual process model combined — are behind how humans solve design problems.
The phrase “dual process model” has its origins in psychology. In the model, computational thinking and design thinking are distinct and ontologically independent processes, and problem-solving in general involves both (although not simultaneously).
One application of this model could be to learn about design tools. Architect Frank Gehry supports technologies that enable a single master model of a building, enabling fluid transition between design thinking and computational thinking. Tools in the user interface enable transition from conceptual design (freehand sketching) to automated code generation. Tools in the future could even enable further fluid transition between these two processes, which is where we conceptualized the early ideas of Shaper.
Conclusions
In this article, I have positioned design thinking with respect to computational thinking, adding to the theoretical underpinnings of design thinking. The suggested ontology situates design thinking and computational thinking as areas in a space of methods for solving problems, with axes of specificity of framing and specificity of solutions. We are now posed with new questions regarding how individuals transition smoothly between these forms of thinking. Well, I think that design thinking and computational thinking are not exclusive of each other; instead, they are mirror opposites of solution and framing.
Subscribe to Our Newsletter
Subscribe to RSS
Press & Media Hub RSS FeedRelated Articles.
More from the engineering frontline.
Dive deep into our research and insights on design, development, and the impact of various trends to businesses.
Article
Jun 19, 2026
We Built a 114-Second AWS-to-Azure Failover. Here’s What We Learned
A practical guide to building a 114-second multi-cloud disaster recovery failover between AWS and Azure — what we built, what broke, and what we learned.
Article
Jun 12, 2026
Cloud-Native and Cloud-Agnostic Are Not Ideologies; They Are Business-Stage Decisions
This blog explains how organizations can balance speed, scalability, and operational flexibility as they grow from startup to enterprise scale.
Article
Jun 8, 2026
Geeklego: The Open-Source Design System Built to Work With AI
Build AI-generated UIs without design drift. Explore Geeklego’s open-source design system, token editor, and AI-powered workflow layer.
Article
May 18, 2026
Your Vibe Code Has No Memory. DESIGN.md Fixes That.
A single Markdown file called DESIGN.md gives your AI agent the design memory it lacks — keeping your UI consistent across every session.
Article
May 14, 2026
Building a Production-Ready Image Cropper in React Native
A practical guide to building a custom gesture-driven image cropper in React Native, with support for both profile and cover photo crops.
Article
Apr 23, 2026
From Manual Testing to AI-Assisted Automation with Playwright Agents
This blog discusses the value of Playwright Agents in automating workflows. It provides a detailed description of setting up the system, as well as a breakdown of the Playwright Agent’s automation process.
Scroll for more
View all articles