Talk on how technical rationality and positivism are common frames for design activities although empirical studies suggest that design does not adhere to what these concepts highlight.
2. Some framing
− This is not about the “right” approach and does not tell the “right”
method.
− Some of the ideas and suggestions in this talk are hard to turn into
practice because they depend on cultural assumption. So if you want
to change something based on it, you may need to start with small
steps.
− If I talk about science, it will often mean “the idea we have of science
as a rational process that finds the truth” (but that was to long, so it
will be “science”)
3. Kinds of problems
− Tame ones: Swap the icons on our website. Add one that does
say “external link”
− Wicked ones [8]: Helping our clients to be more productive using
footool.
●
What does productive actually mean?
●
Is footool the right thing?
●
What doe the clients think?
4. Positivism
Science can find the truth
…quickly replaced by Poppers’
»Science should kick out wrong assumptions«
5. Technical rationality: Process
How professionals should work according to the concept of
technical rationality (see [9][10]):
– Find the problem
– Find the suitable [rational/scientific] method
– Apply method to problem and get the right solution
WIN!
(If that fails, you got a step wrong!)
6. − »We say ›making and invention‹, like ›making an apple pie‹ …
suggesting it is a form of production … [but is is] a complex
process in which goals are discovered, determined and modified
along the way.« Donald Schön [9]
7. We joined the frame of technical rationality
− We “test hypothesis”, “validate ideas”
− “Jan is a user researcher”
8. We joined the frame of technical rationality:
orderly processes
− We use orderly processes
MrJanzen1984
(https://commons.wikimedia.org/wiki/File:Design_thinking.png),
https://creativecommons.org/licenses/by-sa/4.0/legalcode
Kadoictin
(https://commons.wikimedia.org/wiki/File:Design_Sprin
ts.png), https://creativecommons.org/licenses/by-
sa/4.0/legalcode
9. We joined the frame of technical rationality:
right problems
− »Before the sprint begins, you’ll need to have the right
challenge« (http://www.gv.com/sprint/, 30.5.17)
− »Properly framing your design challenge is critical to your
success. Here’s how to do it just right.«
(http://www.designkit.org/methods/60, 30.5.17)
NOTE: I am not “against” aligning on a problem; I want
to show that the snippets suggest that there are “right”
problems
10. We joined the frame of technical rationality:
root causes
− Problems have a specific cause; “We used the 5-Why technique
to find the true cause of…”
− The cause can actually be found: “We found out that the users’
true problem was…”
− Finding the cause, fix the problem: “We thus implemented…”
12. Goals and Problems
Design problems are ill-defined and „wicked“ [8] and it may be not be
possible to „properly“ decompose them.
− »It appears that successful design behavior is based not on extensive
problem analysis« [7]
− Assumed problem and its proposed solution are intertwined [1]
− reframing seems to be essential for the quality of design solutions. [2]
13. Step by step?
Rationality of Design work is signified via demonstrating a process, but:
− Designers don‘t use hierarchical processes (even if they claim they do) [3][4]
− Instead, design activity is opportunistic:
– sudden discovery of new requirements (and often immediate suggestions)[5]
– partial solutions [5]
– If it is cognitively more economic to pursue the goal in another mode (mode=
problem analysis, prototyping…), this is done. [3][4]
(This all does not mean it is arbitrary, there is some order, but not a stepwise one)
14. Step by step?
− »The environment should not embody a method that locks
designers into a strict order of activities« [5]
− Design processes may help novices, but also add mental
bookkeeping load [6]
− »It is not clear whether learning a structured, systematic process
actually helps designers« [7]
15. Summary
− Technical Rationality is the belief in right, scientific, orderly
approaches to invention and innovation
− Often, design work is framed in terms of technical rationality
but:
− Many problems are inherently not clear in the first place
− Large parts of design does not adhere to technical rationality
16. Alternatives
− Changing goals as a sign for having learned more,
not for having failed or being “weak”
− Goals help teams to talk, align, reflect.
− Solutions depend on context instead of the one right method™
− Making sense instead of finding the truth™
− “Understanding users better” instead of phrases that suggest we
find a fixed true thing like “finding needs”, “researching” or
“validating”.
17. 1. 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.
2. 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
3. Visser, Willemien. 1990. “More or Less Following a Plan during Design: Opportunistic Deviations in Specification.” Int. J. Man-Mach. Stud. 33 (3):
247–78.+
4.Visser, Willemien. 1994. “Organisation of Design Activities: Opportunistic, with Hierarchical Episodes.” Interacting with Computers 6 (3): 239–74.
5. Guindon, Raymonde. 1990. “Designing the Design Process: Exploiting Opportunistic Thoughts.” Hum.-Comput. Interact. 5 (2): 305–44.
6. Cross, Nigel. 2011. Design Thinking: Understanding How Designers Think and Work. Oxford ; New York: Bloomsbury Academic
7. 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,
8. Buchanan, Richard. 1992. “Wicked Problems in Design Thinking.” Design Issues 8 (2): 5–21. doi:10.2307/1511637.
9. Technology and Change, Donald Schön
10. The Reflective Practicioner, Donald Schön