We love to ponder about the nature of designing, design behaviours, processes and practices. What is it we do and how do we do it? Eventually, we want to improve how designing is taught and learned.
In a meeting, Theo quickly visualised his understanding of design activity, moving from actual and possibly flawed states to future and desirable states. We discussed the difficulties involved in moving from what is (e.g. through collecting data and information on users and uses of designs) to designs that improve current shortcomings or challenges those designs or situations offer to users.
Seeing that sketch, I immediately though about the parallels to problem-solution co-evolution, a concept in design research pioneered by Maher (1996) and further developed by Dorst & Cross (2001). This concept of design behaviour proposes that designers attempt to better understand a challenge or problem (actual) by proposing early solutions (future), and evaluating their suitability against the problem (e.g. by sketching and constructing porotypes). In this way solutions are proposed, developed and refined. In a research project on novice interaction designers’ behaviour we found that this process can be visualised in detail. You can follow the designer or design team thinking process by the flow it takes from problem (white) to solutions spaces (grey) and back. Designers explore one space in detail and then build a bridge to the other space, but they also develop problem and solution spaces in parallel (grey striped areas). This is how designers frame a problem and creates frames of understanding (red box).
Knowledge about this activity flow helps us to identify techniques, tips and tricks to make the journey between understanding problems and creating solutions much easier in our teaching of designing.
Dorst, K., & Cross, N. (2001). Creativity in the design process: co-evolution of problem–solution. Design Studies, 22(5), 425–437.
Maher, M. L., & Poon, J. (1996). Modelling design exploration as co-evolution. Computer-Aided Civil and Infrastructure Engineering 11(3), 1–22.
Leave a Reply