Models in design
Designing can be considered as an iterative interplay between problem space and solution space where modeling is a key and imperative link between these two spaces.
All cognition is cognition in models or through models.
Herbert Stachowiak, General model theory (1973)
“There is nothing more practical than a good theory,” a statement made by the psychologist Kurt Lewin. I strongly agree with this thought since theory provides a conceptual foundation for practice. Or the other way round, it is theory that helps me make sense of practice. In particular, theory helps me understand why a design process is organized in a certain fashion. Also, being a foundation for a multitude of practical applications, theory allows for flexibility as to how to fine tune a design process and adjust it in a given situation.
The idea that I find essential about designing is “co-evolution of problem-solution”. As Dorst and Cross (2001) suggested: “It seems that creative design is not a matter of first fixing the problem and then searching for a satisfactory solution concept. Creative design seems more to be a matter of developing and refining together both the formulation of a problem and ideas for a solution, with constant iteration of analysis, synthesis and evaluation processes between the two notional design ‘spaces’ — problem space and solution space. The model of creative design <…> is based on such a ‘co-evolution’ of the problem space and the solution space in the design process: the problem space and the solution space co-evolve together, with interchange of information between the two spaces.” In other words, a designer aims at coupling and considering together the present situation (problem space) and a desired future state (solution space). The more detailed description of the present situation a designer compiles, the more boundary conditions are being created; and vice versa — elaboration on a particular solution can illuminate overlooked details of the problem. It means that a design process is iterative rather than linear problem solving. Together with that, co-evolution of problem and solution does not mean that they are connected directly. In reality, problem and solution are coupled via models. By means of models a designer is able to frame and make sense of a present situation, reframe it and, eventually, shape an alternative future state. To put it another way, it is models that facilitate a designer to progress gradually from problem towards solution. On top of that, models foster collaboration between everyone involved as well as create a shared vision of an endeavor.
Design process
Let’s consider two models of a design process — The Innovation Process as Learning Model and The Analysis-Synthesis Bridge Model. Both of them uncover essential aspects which help in understanding the nature of a design process.
As The Innovation Process as Learning Model (by Beckman, Barry) suggests: “An ideal learning cycle is one in which the learner goes through all four phases — experiencing, reflecting, thinking, and acting — in a recursive process that is responsive to the learning situation and what is being learned. Immediate or concrete experiences are the basis for observations and reflections [observation to frameworks]. These reflections are assimilated and distilled into abstract concepts from which new implications for action can be drawn [frameworks to imperatives]. These implications can be actively tested and serve as guides in creating new experiences [imperatives to solutions and back to observation].” (Beckman, Barry)
The Analysis-Synthesis Bridge Model (by Dubberly, Evenson, Robinson) is described as follows: “The left column represents analysis (the problem, current situation, research, constituent needs, context). The right column represents synthesis (the solution, preferred future, concept, proposed response, form). The bottom row represents the concrete world we inhabit or could inhabit. The top row represents abstractions, models of what is or what could be, which we imagine and share with others.”
Both models are shaped as a two-by-two matrix; they reveal the structure and describe the essence of a design process which is, to me, lays in interplay between the concrete, abstract, analysis, and synthesis. It is the transition between concrete (What is & What could be) and abstract (Model of what is & Model of what could be) that I’ll be pondering about in this text.
Based on models presented, the design process can be described in four steps:
1. Observations / What is. Design work begins in the concrete realm. This step is devoted to research and gathering data about a product/service strategy as well as customers & users, their context of use, goals, and needs. A designer aims at deconstructing and analyzing the present situation in order to articulate circumstances that make the project actual from both customers & users and business perspectives.
2. Frameworks / Model of what is. Design process moves on from the concrete to abstract realm. This step implies interpreting research data and transforming it into information and, eventually, into knowledge about the present situation. A designer accomplishes this by means of framing, sense making, and reframing.
3. Imperatives / Model of what could be. Still being in the realm of abstractions, this step is a place to speculate on alternatives that can potentially resolve customers’ & users’ needs and address business goals. A designer applies synthesis to outline what a possible future can look like.
4. Solution / What could be. Design process returns from abstract to concrete realm. At this step, a concept — a model of a preferred future — can be transformed into tangible artifacts. A number of possible solutions can be prototyped and tested. Testing prototypes entails that the design process goes over the Observations step again in iterative fashion.
Apparently, co-evolution of problem and solution does not imply that these two are tied directly. Rather, the connection between problem and solution is indirect and goes via two intermediate stages of a design process — Model of what is (or Frameworks) and Model of what could be (or Imperatives). Kolko (2015) suggests that “Modeling delineates between problem finding and problem solving, acting as a form of problem understanding.” It is models that facilitate a designer to progress gradually from problem towards solution.
Models
Let’s elaborate on the notion of model. “Models are ideas about the world — how it might be organized and how it might work. Models describe relationships: parts that make up wholes; structures that bind them; and how parts behave in relation to one another.” (Dubberly, 2009) In science, models are used “to represent and increase information. The core purpose for using models is the simplification, visualization, idealization, modification, or hypothetical realization of phenomena together with the aim making the latter easier to understand.” (Hof, 2018) In other words, models are abstractions which reflect one’s understanding of the world.
Models are a fruit of observation, framing, and making sense of reality. Observation implies gathering data that reflects a present situation and provides material for further work. Framing a situation means setting up boundaries based on product/service strategy and one’s subjective perspective. This way, framing helps to highlight “a few salient features and relations from what would otherwise be an overwhelmingly complex reality.” (Hideaki) Sense making is understanding relationships between seemingly disparate pieces of a framed thing. Framing and sense making together facilitate extracting essential and relevant features of the situation as well as understanding its structure. Ultimately, as Mittelstraß (2005) put it, “Models [are] neither true nor false but rather strongly applicable or weakly applicable <…> They are determined by a pragmatic criterion, not a truth criterion.”
To underpin the idea that models is the medium between problem and solution in their co-evolution, Dubberly (2009) suggested two important aspects of models:
- Observations suggest models. Models originate in data which reflects a present situation. Once gathered, data can be organized, interpreted and, eventually, transformed into models that represent a situation.
- Models guide actions. As it was mentioned above, models are used for simplification of a phenomena. By representing only relevant and essential aspects of a new situation, models help recognize similarities with already known one. This way, models allow to navigate through unknown and act based on one’s past experience.
Stachowiak (1973) suggested that “All cognition is cognition in models or through models.” Nowadays, cognitive scientists think about models as an “epistemic tool” (Boon, Knuuttila, 2008). Models comprise knowledge about a present situation, and this knowledge has been worked out by means of observation, framing and sense making. It is knowledge that fosters a designer in their progress from problem to solution. Ultimately, as Dubberly (2009) put it, “models help bridge the gap between observing and making.”
Models in UX and Service design
Models link two design spaces — problem space and solution space. Being abstracts, they occupy the abstract realm of the design process schema. Since models are suggested by observations, a designer steps in the abstract realm only in the aftermath of the concrete part of the process. Next, as models are supposed to guide actions, a designer returns to the concrete world in order to embody ideas.
Two types of models — Models of what is and Models of what could be — help a designer in describing problem and solution respectively. Besides models as artifacts, different modeling methods can be applied (for instance, “How Might We” Questions or SCAMPER) which allow to formalize thinking with models. Ultimately, thinking with models facilitates movement from analyzing a problem towards synthesizing possible solutions. Such methods will be listed below along with models.
There’s one more important aspect of employing models. Developing them stimulates collaboration between everyone involved in a project. As a result, models visualize and represent a shared understanding of a problem and solution.
Models of what is
Models of what is are aimed at describing and interpreting (or making sense of) the present situation and inherent problem. A designer accomplishes this by analyzing research data and transforming it into information and, finally, into knowledge. The list Models of what is can comprise:
- Product Strategy,
- Business Model Canvas,
- Fishbone Diagram,
- Concept Map,
- Ecosystem Map,
- Job Story,
- Empathy Map,
- Persona,
- Task Analysis,
- User Story Map (as is),
- Service Blueprint (as is),
- Problem Statement,
- “How Might We” Questions.
Models of what could be
Models of what could be help a designer envision what the preferred future looks like. Now synthesis becomes the primary method of design work making it possible to explore alternatives that can resolve users needs and reach business goals. Models of what could be can include the following:
- User Story Map (to be),
- Service Blueprint (to be),
- Value Proposition Canvas,
- Customer Lifecycle Map,
- SCAMPER,
- UX Flow,
- Prototype.
Both types of models are depicted below on the design process diagram:
What is listed and illustrated above is not the comprehensive list of models and methods. There exist various models and modeling methods which can be employed during a design process to facilitate framing, making sense and reframing of the present situation as well as, ultimately, foster synthesizing of an alternative future.
Conclusion
Modeling is invaluable instrument in any type of design practice. Although it is prone to be exercised implicitly or even omitted in real design work, modeling deserves time and efforts. Instead of jumping straight into the Solution step of a design process, it’s imperative to step aside into the realm of abstractions to create models of what is and models of what could be that facilitate the co-evolution of problem and solution.
Thanks for reading!
Feel free to reach out via LinkedIn.
The article was first published on coherentsolutions.com.
