I’ve applied for a speaking position for Relating Systems Thinking & Design 2013 at the Oslo School of Architecture and Design. My submission is toward the wonderfully punctuated theme of “teaching (systemic design or), system thinking in design (or design in system approaches).”
Here is my abstract:
The goal of this talk will be to communicate the approach and outcomes of a 16 week studio course developed over the past two years to teach systems thinking to undergraduate interaction designers at the California College of the Arts (CCA) in San Francisco. The plan for the final presentation is to provide symposium attendees with a narrative describing the thinking behind the course design, learning objectives, and activities as well as a report of my experience teaching and revising the course over the past two years. The value to attendees will be as a model and case study of one successful (as judged from student feedback) approach to relating system thinking and design.
The course was developed as part of starting up an entirely new undergraduate program in Interaction Design at CCA. The vision with which I won the commission to originate the course framed the learning objectives as a growth process beginning with learning to see the systems around us, moving on to being able to model them conceptually, and closing with how to produce change in them, both in a general sense and within the context of interactive experiences.
My first step in translating this vision into a workable syllabus was an extensive online search of the public web for like syllabi. I found essentially zero publicly available references that addressed my proposed framework directly. This was when I realized I actually needed to design this design course!
I saw this innovation challenge mainly in term of creating a new, dynamic narrative for existing formal system thinking constructs that would make these ideas relevant to the digitally native sophomores (roughly 19 year olds) taking the course. Therefore, I opened the course with a lecture in which I use a ‘ripped from the headlines’ method to demonstrate both how designing interactive experiences in today’s world requires an understanding of systems and also how to use observations of events to see a system in terms of patterns, structure and containing context.
After setting the stage to begin a formal presentation of system thinking theory I pause for us to read out loud a love story: Arcadia, a play by Tom Stoppard. This masterpiece packs a doctorate’s worth of system thinking constructs–including time, structure, entropy, fractals, abduction vs induction and probability–into a 2.5 hour experience. But most importantly it provides a mechanism for me to communicate to the students the critical role that emotion plays in human systems. This becomes the implicit frame for the rest of the course.
Next we turn to the fertile time just after World War II in which thinkers at Massachusetts Institute of Technology more or less simultaneously developed Information Theory, Cybernetics and System Dynamics. We begin the conversation with System Dynamics because it is the most intuitive and least mathematically intimidating of the three. We use Donella Meadows’s wonderfully accessible “Thinking in Systems” as a basis for studio discussion and activities that bring to life the idea of a system as made up of stocks and flows. From this base we expand the definition of a system to “a structure of relationships between elements that accomplishes a purpose and is regulated by feedback.” This provides a frame to talk about system archetypes and the importance of patterns as a tool for system analysis.
The general behavioral patterns introduced by archetypes provided a segue to the formal treatment of regulation and control offered by Cybernetics. The main goal of this part of the course is to provide students with a way to see certain kinds of man-made systems as machines with inputs, outputs, predictable behaviors and discrete states. This ‘mechanical’ understanding of systems becomes a conceptual a bridge between the the initial ‘seeing systems’ material and the next phase of the course that I call “designing the digital machine.”
In this phase we use the idea of a digital machine to create a bounding framework for the application of modeling as a tool for designing interactive experiences. I introduce 5 specific models–conceptual, persona, data, object, interaction–and teach how they fit within the model-view-controller framework that describes software flow control, or the digital machine. We close out this phase of the course with a major project in which students develop models of a system with feedback and then use those models as the basis for a software interface.
The narrative for the final phase of the course uses the framework of Rittel’s Wicked Problem to create a launching pad for the students into an optimistic and aspirational future. The story we tell is that Rittel defined the wicked problem to explain the increasingly obvious failure of capital D Design as a top down planning exercise to solve social problems. This in turn led to a roughly 50 year period in which design played a minor apolitical role of delivering delight at an individual level. However, (the course narrative continues) for the interaction designers of today a new opportunity has arisen to combine an understanding of systems with the time compression of high bandwidth connectivity, device diversity, cloud services, and social networking to create bottom up mitigations for social problems. Students are then asked to work in teams to design an information system focused on mitigating communication challenges within a particular wicked context: in the first year we looked at the distribution of organic produce; in the second, the fishery supply chain.
What is Digital Machine Theory?
It is a method I am developing to teach systems design to interaction design students.
I believe the theory demonstrates how to connect classical systems theory of the Forrester/Meadows school to the practice of interaction design.
The primary assertion is that interaction design may be understood as the design of a digital machine defined in terms of cybernetic principles.
I am not familiar with the terminology used to describe Digital Machine Theory. Do you have a plain language presentation?
Why yes, I do!
I have prepared a series of 6 short lectures that explain the theory in plain language:
- What is a system?
- From System to Software
- The Conceptual Model
- The Interaction Model
- The Object Model
- The Data Model
What is the value of digital machine theory?
I propose the theory has value as:
- a theoretical framework to train individuals in the basics of software design practice
- a communication framework for planning the design or redesign of a software application
How did you come to develop it?
It is an outcome of my work as adjunct professor at California College of the Arts Interaction Design Program. I teach a course called Systems to undergraduates.
Why are you calling it a beta release?
Because I am a nerd. Also because I feel like beta sets an appropriate (in my world, at least) expectation for the quality level of both the theory itself and the materials I have put together to explain it. I think it has some good bones, but the whole thing needs some banging on still. Do so and send me comments, timsheiner at gmail.com.
Aside from “which is better for wireframing, Illustrator or Omnigraffle?” the most common perennial question on UX design forums and list serves is some variant of “how do I convince management to invest in design?”
The reason this question comes up again and again is that the answer is not what anyone wants to hear: it can’t be done.
You simply cannot convince someone with words that design (or design research) is a valuable approach to solving problems.
The only way a person comes to believe in the value of design is to feel it for themselves. He or she must personally go through the transformative emotional experience of watching the human centered design process do the magic it does. Nothing else works.
This would seem like an insurmountable problem: the only way to get a sponsor to support design is to have him go through the experience of the thing that he won’t support.
OK, it is a tough problem, but it is actually not insurmountable. Here are the three approaches that have worked for me.
A fact of human nature is that, except for psychopaths, no person can ignore someone else’s emotions when confronted with them. This means that one way to get a design skeptic to give it a try is to get someone else to share with him positive emotion about his own personal experience learning about the value of design. Of course, getting the testimonial, and getting it in front of the skeptic in a format they can consume are separate challenges you must solve.
The words “pilot project” when wrapped around risk, give all stakeholders a way out should the thing go south. You still have to find executive sponsorship for your ‘pilot project’ but this is more likely to happen when that executive can explain it upward and downward as a known and contained risk.
As An Alternative to Bupkis
In this approach, you must first identify something that is well and truly broken that design might fix. If you prove consensus that you’ve identified a real problem, and particular one costing money and time, then your new approach of design, risky as it sounds, looks like a reasonable gamble in the face of no alternative plan for an ongoing and worsening situation. Of course, this one is something of the nuclear option: you fail here (and if the problem is that hard you very likely may), you do not get a second chance.
A very short post to share a simple formulation I have developed for explaining the relationship between the models I find most central in developing interactive systems.
First, a high level statement presenting the models and their relationship:
<business model><interaction model><system model>.
My meaning with respect to the “><” is that you can read this statement from left to right or right to left, or start in the middle. This is because all the models are connected through feedback loops.
Your choice about where to begin depends on what you know initially, what most interests you, or what direction you want to drive change.
A presentation of the overall system of models in a tree, with more detail about their respective composition is this:
- Business Model
- Value Proposition
- Cost Model
- Revenue Model
- Interaction Model
- Conceptual Model
- Object Model
- Data Model
- Error Model
- System Model
And there it is.