TL;DR: Design methods are often based on in ideas that were popular in the early 20th century: scientific positivism and industrial production. This hides essential, but messy aspects of design.
In his book The Reflective Practitioner, Donald Schön uses a concept named “Technical Rationality”. It is the idea, that there are clear problems, clear solutions and processes which provide the path from problem to solution, all based on science. Practitioners apply these processes that are given to them by science; then they build what the process suggests as a solution. Because of this, practitioners have a lower status, since all the intellectual work is done in the science-part of the concept.
In The reflective Practitioner 1 Schön connects this to the idea of positivism: Scientific positivism–very simplified–assumes that only empirical data and logic should be used to generate valid knowledge; findings can be verified; the social behaves according to universal laws (similar to physics).
Another idea can also be connected to the approach of technical rationality: Industrial production. This is less present in the reflective Practitioner, but in his book Technology and Change 2. The idea of industrial production is that processes can be split into clear steps, just like products are assembled step wise in a production line. Each steps can be optimized on its own and takes the previous’ step’s output to convert it to input for the next step 3.
Technical Rationality in the design process
The foundations of technical rationality, scientific positivism and industrial production are not very popular. Scientific positivism is philosophically really dead 5. The industrial production on assembly line is widely used, but our future is said to be the knowledge economy, self-organized teams and agile processes.
Nevertheless, technical rationality is alive –also in design. This is reflected in the rhetoric we talk in order to teach, explain and justify design:
Claims of Foundations in natural sciences producing truth
We talk about findings being verified and product ideas being validated, like findings in positivism. The job title of a user researcher conjures the image of natural or at least empirical science.
Processes are presented as orderly, step-wise and based on the idea of input/output in each step
Design processes are often represented in a linear and step-wise way. That matches the idea of the design process as a production line, with clearly marked steps that feed each other input. Even though some processes highlight the possibilities of iteration, there is still an assumed usual order of steps.
Believe in the existence of a right problem that should be tackled
The “right problem” is the start of the process in technical rationality. It is the very first step before you apply (empirical) methods to solve your problem, so it needs to be somehow bootstrapped. This first step is highlighted as essential in popular design methods:
“Before the sprint begins, you’ll need to have the right challenge”
– (Google Ventures Design Sprint, 30.5.17)
“Properly framing your design challenge is critical to your success. Here’s how to do it just right.”
–(IDEO.org’s Design Kit on “Frame Your Design Challenge”, 30.5.17)
The technical rationality view of design processes clashes with philosophical and empirical views on design
These basic assumptions of scientific foundations, step-wise processes and root problems conflict in several ways with design philosophy and design research:
Design as scientific process
Design is not the same as science: Nigel Cross described “Designerly Ways of Knowing” : While natural sciences are concerned with the natural world and values like “objectivity, rationality, neutrality, and a concern for ‘truth’” 8, design is concerned with the “man-made world” and values as “practicality, ingenuity, empathy, and a concern for ‘appropriateness’” 8.
This is matched by empirical research of design processes: Rogers described methodological frameworks and contrasted them with practicioners’ opinions. Theories were not practical for most designers 12. Other studies on method use by designers yielded similar results, e.g. 11 16. The complexity in the design process can not be adequately handled by current scientific theories 10.
Design as a non-linear process
Rationality of Design work is shown by having a process. But designers seem not to use a process that is divided into clear steps. For example, no hierarchical problem decomposition takes place, even if the designer claims it does 14 15.
According to methods like design thinking (or at least according to simplistic implementations of it), requirements should be defined before building a prototype, but it seems that designers discover and add requirements in the process of creating solutions 17. The modes like problem analysis or prototyping are switched if it is cognitively more economic to use another mode 14 15–and this is not always when a method suggests it.
Design Research on “Right goals”: Solution and problem are both changed over time
Design is a way to solve entangled, “wicked” problems that have unclear conflicting constraints, multiple stakeholders with different needs, and in which creating a solution also changes the context 6. A design problem’s wickedness conflicts with the basic premise of having the “right problem” at the start of the process. The assumption of a single root cause (like in the popular 5-Why method) can lead to simplistic views 19.
The assumption that finding the “right goal” is essential is also not supported by design studies 20. “It appears that successful design behavior is based not on extensive problem analysis” 7 One reason for this might be that there are no inherent “right goals” in design—on the contrary: The assumed problem and its proposed solution are intertwined 9. This means, that when the solution is developed also another understanding of the problem is developed. This reframing—a problematic behavior when viewed from the assumption of “right problems” seems to be essential for high quality design solutions 13: To stick with one right problem can actually hurt in finding a right solution.
Many design methods are based on the assumptions of technical rationality and use positivist ideas of research and verification as well as production line models with stepwise creation of a solution. These ideas conflict with views based scientific and philosophical studies of design:
- Design can not use the same principles as science
- The wickedness of many interesting problems defies essential assumptions of clarity of problem and solution.
- There does not seem to be a strict order of steps and the methods applied in them (but an opportunism of the use of whatever seems to work best)
In practice, the clash between technical-rational assumptions and practice21 may hinder good outcomes e.g. by keeping people from rewriting their goals and discouraging jumping between methods. They may also obscure the strengths of design: It’s applicability to wicked problems, where no root causes can be found.
We should not be aware that popular design methodologies often come with their own assumptions, assumptions which often embody 20th century ideas of industrial production and science.
- Updated at 2017-09-27: Reference to Gedenryd’s How Designers Work.
- Updated at 2017-12-19: Footnote on relation to The politics of formal representations (S.L Star) added.
Frames of industrial production and positivism in the design process by Jan Dittrich is licensed under a Creative Commons Attribution 4.0 International License.
Schön, Donald A. The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books, 1983. ↩
In his Book “Technology and Change”, Donald Schön describes that innovation is often framed similar to production [p. 8]: Schon, Donald A. Technology and Change. First Edition. Pergamon Press, 1967. ↩
Gedenryd, Henrik. 1998. How Designers Work. Lund University Cognitive Studies 75. Lund: Lund University. ↩
In science philosophy positivism has been replaced by various other theories. One reason was that hypothesis can not be proven, only falsified, as Karl Popper showed in The Logic Of Scientific Discovery (Which then was criticized and build upon by other philosophers). More at Wikipedia: Postpositivism and Stanford-Plato:Logical Empiricism ↩
Buchanan, Richard. 1992. “Wicked Problems in Design Thinking.” Design Issues 8 (2): 5–21. doi:10.2307/1511637. ↩
Cross, Nigel. 2001. “Design Cognition: Results from Protocol and Other Empirical Studies of Design Activity.” In Design Knowing and Learning: Cognition in Design Education, edited by Eastman, C.;, Newstatter, W., and McCracken, M., 79–103. Oxford, UK: Elsevier, ↩
Dorst, Kees and Cross, Nigel . 2001. “Creativity in the Design Process: Co-Evolution of Problem–solution.” Design Studies 22 (5): 425–37. doi:10.1016/S0142-694X(01)00009-6. ↩
Goodman, Elizabeth, Erik Stolterman, und Ron Wakkary. „Understanding interaction design practices“. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1061–70. ACM, 2011. ↩
Gray, Colin M. „‚It’s More of a Mindset Than a Method‘: UX Practitioners’ Conception of Design Methods“. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, 4044–55. Santa Clara, California, USA: ACM, 2016. ↩
Rogers, Yvonne. „New theoretical approaches for human-computer interaction“. Annual review of information science and technology 38, Nr. 1 (2004): 87–143. ↩
Valkenburg, Rianne, and Dorst, Kees . 1998. “The Reflective Practice of Design Teams.” Design Studies 19 (3): 249–71. doi:10.1016/S0142- 694X(98)00011-8 ↩
Rosson, Mary Beth, Wendy Kellogg, und Susanne Maass. „The Designer As User: Building Requirements for Design Tools from Design Practice“. Commun. ACM 31, Nr. 11 (November 1988): 1288–1298. doi:10.1145/50087.50090. ↩
Guindon, Raymonde. 1990. “Designing the Design Process: Exploiting Opportunistic Thoughts.” Hum.-Comput. Interact. 5 (2): 305–44. ↩
Lowgren, Jonas. 2007. Thoughtful Interaction Design: A Design Perspective on Information Technology. New Ed. Cambridge, Mass.: Mit University Press Group Ltd. ↩
An alternative framing which does not carry the fixation on the “true” problem is made by Löwgren and Stolterman: “We may note that a designer’s current understanding of the design situation is commonly referred to as the ›problem‹, and her ideas on how to proceed are called ›solutions‹ 18” ↩
Susan Leigh Star provides an interesting analysis of how people work with formal representations. Since representations need to simplify and leave out parts of what they represent, people invent strategies of how to accomodate both the formalized representation and the practices that are not represented, but needed in the context of the current problem:
1) Freezing parts of the implementation to adhere to the formalisms easing to standardize and to predict at the cost of not optimizing for the situation at hand.
2) Relying on Wizards who solve problems by thinking across the boundaries of the representations at the cost of creating non-communicated, tacit, private knowledge being now an essential part of the design.
3) Attempting to model "tacit Knowledge" by modeling what the Wizards do at the cost of this being hard, since much of the tacit knowledge is build and working in a specific context of a project or organization and…
4) denigrating the social as impure and thus split how one thinks about a problem into a technical-rational part and a social part. What can be controlled and structured goes in to technical-rational, what causes problems and is messy goes to the social part at the cost of having created just another representation that does not reflect the problems that occur and further preventing research and understanding aimed to question the model since that reserach can also be labeled as “social”. — Based on Star, Susan Leigh. "The politics of formal representations: Wizards, gurus, and organizational complexity." Ecologies of knowledge: Work and politics in science and technology (1995): 88-118. ↩