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.
I am teaching my systems course at CCA for the second time this spring. Student feedback from the first time was really positive, and I learned a great deal that I’ve built into this updated version.
At the high level, I’ve broken down the course like this:
- Weeks 1-4: Classical System Theory
- The Emotional Content
- Classical Systems
- Weeks 5-9: Systems and Software Design: Conceptual, Object & Data Models
- Conceptual Model
- Object & Data Model
- Error Model
- Interaction Model: La Enchilada Completa
- Application One: Final Presentation
- Weeks 10-15: The Nature of Wicked Problems & The Opportunities for Software Mitigations
- The Web Interface Context
- Wicked Problems
- The Organization as Context
- Software Mitigations
- The Application as Narrative
- Application Two Final Presentation
For all the details, here is a link to the full syllabus:
UPDATE – 10/21/12
One day after including an @zipcar in a tweet about this post, I received a call from Veronica at my local Zipcar office.
She explained that, being in my local office, she had a bit more control over my account than the person I’d spoken to previously at the call center.
She offered to re-instate my account to honor the non-refundable year subscription I’d paid for, and also to set it to automatically expire, rather than roll over, on its anniversary.
I accepted her offer. The romantic ride up the coast in a convertible may yet happen.
I just recently quit my subscription with Zipcar.
This was not because of a problem. Prior to ending my relationship with them, I had no issues with their product. In fact, I was kind of impressed. I’d thought the sign up process was pretty slick and efficient. I had used a car one time and found the experience simple and satisfactory.
But then my situation changed. For various reasons, totally unrelated to the Zipcar experience, my wife and I decided it made sense for us to buy a second car. With this car, I was no longer going to need a Zipcar. And even though I’d committed to a year subscription only a few months before, I decided that, while I was thinking about it, I’d cancel my subscription so that I didn’t forget about it and have it automatically renew.
I assumed that I could cancel online.
I had to call a number and deal with a person whose job it was to convince me not to quit. She was reasonable, and polite, and got efficient when I made it clear my decision was made. But still, this didn’t feel very good.
I had assumed that even though I was canceling, as I’d paid for a year’s membership, I’d stay a member until the term ended. I had visions of splurging on a sexy convertible for a drive up the coast with the wife or something.
My ability to rent a car was terminated as soon as I cancelled the subscription, even though I’d paid for a year already, and no refund was coming to me. That didn’t feel good either.
I had assumed that as soon as I quit my subscription, I’d stop getting the annoying promotional emails from Zipcar that I’d never opted into in the first place.
None of these behaviors are entirely unreasonable, nor is any one of them particularly egregious.
However, they do tell a sad story.
The narrative arc of this story is how a person, me, who had a really positive brand image of a company he thought was cool and innovative but from whom he no longer needed service is taught, as the door hits him on the way out, that said company has a sales-driven corporate culture that understands customers only as individuals from whom the company is currently making money.
My feelings were hurt, but I’ll get over it.
However, if I ever decide that I, or perhaps my soon to be driving teenage sons, need a car sharing subscription, I’ll look somewhere other than Zipcar.
I took BART from 24th and Mission in San Francisco to 19th and Broadway in Oakland and then walked down to the Kaiser Auditorium on Lakeshore Drive. As I emerged to the street and took in the striking serpentine-green I. Magnin building I noted that feeling I always get when I go to Oakland, namely, that what I don’t know about Oakland could sink a battleship. It was 8:15 am on a Saturday morning, rainy, gray and very quiet.
The Kaiser Auditorium building impresses from the outside with its scale. It has a grand modernist persona distinctly distinct from the art deco environment I’d just walked through. A small paper sign on the door invited me to walk around back for Code for Oakland.
On the inside the modernist theme continued with floating escalators that brought me up to the mezzanine level past a black and white photo homage to Henry J. Kaiser that felt like looking at a 60’s era LIFE magazine. I was warmly greeted at the Code for Oakland registration desk, grabbed a muffin, some coffee and sat down to wait for I wasn’t sure what.
The lobby was buzzing with the hum of 100 people or so when, at 9am, we were asked to sit down in the auditorium. Susan Mernit gave a nice welcome and clear overview of the day, then we embarked on what I thought was a brave endeavor: a brief self introduction by everyone in the audience!
My concerns were completely misplaced; the experience was fascinating. The diverse crowd skewed white/male/geek but far, far less than any tech event I have ever been to with lots of women and people of all colors. The professional breakdown seemed to be along a non-profit to tech continuum with a few student and government outliers. As I listened to the different voices explaining their respective reasons for volunteering their Saturday, I wondered what factor was the biggest diversity driver: #gov20 or Oakland?
After introductions we were asked to self select into groups to work on the project ideas that had been collected in earlier community meetings, and during the self-introductions. I was pleased to find some interest in the idea I had suggested to create a simple SMS messaging system for community organizers. After some milling about the groups moved into the lobby and settled down around the tables set up there.
Our team consisted of myself, Ryan Jarvinen (@ryanjarvinen), Lamont Nelson (@thelamontnelson), Alan Palazzolo (@zzolo), and Keith Tivon Gregory (@tivon). Except for the extreme gender bias, we were a reasonable mirror of the diversity in the larger group; as the lone Gen X-er (and just barely squeaking into that cohort!) I significantly raised the average age of our otherwise solidly Gen Y crew. Our overlapping skill sets easily covered experience design, front and back end coding we would need for our project.
As we began brainstorming about the product, which we named ‘ComTxt’ (COMmunity TeXTing), two key ideas emerged. First, a crucial success factor for community organization is the ability to provide the community with notifications (of upcoming meetings, actions, notable successes, etc.). Second, the one technology constant among groups of diverse racial and/or socio-economic status (as might be found in an urban neighborhood or as the parents in a public school) is text messaging. Certainly email is common, but it is by no means ubiquitous, and while phone trees can work, they are inefficient and manually intensive. Essentially everyone, however, has an SMS-capable mobile phone these days. Therefore, a system that enabled an organizer to broadcast text messages to a community of subscribers would be a useful tool for advancing community process.
We transformed these observations into a simple vision: a mailing-list for text messages. With this “good-enough” consensus on the basic product vision, we created some sketchy personas (PTA president, teacher, neighborhood activist) and very simple use cases for each. The PTA president use case was representative: instead of having to collect email addresses at each PTA meeting (and then manually transcribe them), with ComTxt she would be able to display a simple poster that told anyone wishing to receive updates from the PTA to text the name of the school to a particular number.
After a brief break to consume the satisfying and complimentary lunch of sandwiches, chips and cookies, we began to identify the technologies and frameworks we’d use to build our proof of concept. At this point we had about 4 hours left before the team presentations would begin at 4:30pm. I was silently dubious that we could go from zero code to a working prototype in that amount of time. My partners were relatively unconcerned because they understood something I had not yet internalized: we weren’t starting with zero code.
In fact our starting point was the remarkable world of frameworks, APIs and services that is the current web development environment. The programming reality of today is that there is so much pre-existing functionality, documentation and examples available via a web browser that no online project ever starts from zero. My team’s ensuing discussion of exactly which API or service to use was largely over my head, and though I am certain real nuances were being discussed, I think the guys would admit the discussion wasn’t much different than debating which is the best tacqueria in San Francisco. In the end I believe we ended up creating a node.js solution that connects with the Twilio platform, but I may have missed an abbreviation or two.
By this point in the process we had made a seamless and almost unspoken transition from group process to each of us executing as individuals on the tasks to which we were respectively best suited. Ryan gathered and returned to us information about the pros and cons of various text messaging platforms he’d learned from other groups, and he set up the Github repository we’d be using. Alan and Lamont dived into the details of our chosen APIs and began writing the code to implement the simple set of commands ComTxt would understand. Meanwhile, Keith and I collaborated on a prototype web UI for accessing the service, complete with some initial ideas about branding including a logo.
And suddenly it was 4:15 and our prototype didn’t work! Undeterred, we quickly agreed on how to replace our planned demo with a PowerPoint show which I was still finishing even as I moved from our work table into the auditorium to watch the other teams present.
Watching the other presentations I began to feel like I was seeing the beginning of something real and transformative, even if I still couldn’t exactly articulate what it was. Gov 2.0 may not yet be truly changing lives, but I am certain it will and soon. Last Saturday I saw one good, and useful, idea after another presented and in most cases actually working with a degree of polish and functionality that was remarkable given the few hours the teams had had to create them. I got an emotional thrill from the energy and enthusiasm for positive change that had coalesced into these fascinating projects.
Literally moments before our turn to present, Alan, grin on his face, leaned over and told me the system was working! It turns out as I had been watching the other presentations spellbound, he, Lamont and Ryan had continued coding and had solved the blocking issue. I rapidly added a telephone number to our title slide and we all went up to present. The audience understand our simple idea right away and shared our smiles when, after texting a subscription request to ComTxt, our phones buzzed in unison with a message from Alan:
Code for Oakland is great!
Sent from ComTxt
My friend and Jaspersoft colleague Matt Dahlman recently forwarded me a nice image he’d made that captures the essence of JIF, our new interface framework. In Matt’s words:
The attached image shows the actual HTML code behind the menus that a user sees in v3.7 vs v4.0. It makes the idea pretty clear that a developer will find this new system cleaner, easier to customize, and generally better.
Thanks Matt, this is a great way to visualize the simplification JIF has brought to JasperReports Server.
Truth is, we’ve actually made things 3 times simpler than even this picture shows!
Matt is actually showing only one of the 3 different menu systems in 3.7. Yes, believe it or not, in the bad old pre-JIF days JasperServer had 3 totally different menu systems, each used in different parts of the application. These menus did not share markup, logic or presentation code and learning to customize one didn’t teach you a thing about customizing either of the other two.
JIF has a single menu system for the entire application with a simple, standardized method for customizing content and appearance.
Just what you’d expect from a state of the art interface framework.
Just trying to understand how this works.