Photographers have a catchphrase: “It’s not the camera you have, it’s what you do with it.” (You sometimes hear this variation: “It’s not the camera, it’s the photographer.”) What this means is that the tools you use are less important to outcomes than your degree of mastery over the subject. An experienced photographer will make excellent images with a crappy camera, whereas someone who doesn’t know what he or she is doing will mess things up even with top-of-the-line equipment.
My systems class involves making lots of diagrams. Diagramming software (e.g., OmniGraffle, Visio, and Adobe Illustrator) is often intimidating to students who don’t have design backgrounds. Some assume they must master one of these tools before they can create clear, elegant diagrams. I disagree; the minimum denominator — PowerPoint — will do fine in a pinch.
You don’t need to master “big” software to create great diagrams. Instead, you need:
An understanding of who the diagram is for. Are you the audience, or is it someone else? Do they have particular ways of understanding the space that will influence representations?
An understanding of the purpose of the diagram. What are you trying to explore or convey? What is the framing question the diagram seeks to answer?
An understanding of how to break things down into their constituent elements. What elements should be included/left out of the diagram? Will all elements be represented at similar levels of granularity, or will some be broader than others?
An understanding of how to represent relationships between elements. Do some influence others? Are relationships one-way? Two-way? One-to-one? One-to-many? Many-to-many? Are some elements containers for others?
Feedback. Are people getting it? Is it clear? What can be improved?
None of these things require software; you can explore them using pen and paper. The more you do it, the better you become at it — and the better you become at it, the better you will be when it comes time to wield the big diagramming tools. Practice is the key; becoming good at it using simple tools will keep you focused on the things that truly matter. Then you can learn the more powerful tools with the confidence that you know what you’re doing.
Systems theory can be quite abstract. I’ve set for myself the challenge of making the subject come alive for my students at CCA. This week, we covered simple dynamic systems. (“Clockworks” in Ken Boulding’s classification scheme.) To help make the subject tangible, I led students on a field trip to Fort Mason.
After the visit to The Interval, we strolled to another part of the Fort, where I delivered a short lecture while students sat (unbeknownst to them) on Christopher Alexander’s bench facing Alcatraz. It was a beautiful setting, and towards the end of the lecture, I revealed the bench’s backstory. The students had read Alexander’s A City Is Not a Tree before class; discussing the subject on a structure designed by the architect (albeit a modest one) was a rare privilege. (I’m grateful to my friend Dan Klyn for making me aware of the existence of this bench.)
We ended class with a brief group juggling exercise that illustrated the importance of structure when dealing with simple dynamic systems. The setting was perfect — a clearing among the buildings, facing the Bay — if a little cold. But the chilly breeze gave the exercise a sense of urgency that would’ve been hard to simulate otherwise.
It was a great, content-packed — and fun — afternoon. I consider myself lucky to be able to teach this subject here. While systems are indeed everywhere, the most enticing ones are not evenly distributed. The Bay Area has some of the finest examples in the world, if you know where to look.
When I was a student, I had a very dualistic understanding of how the world works. Architectural projects were either the-best-thing-ever or utter shit. There was no in-between. I venerated the designers of glorious projects, overlooking their flaws. I assumed the people who made shitty ones were completely clueless. Why would they make such crap?
Now that I’ve been working for a long time, I understand designers don’t have complete control over the work. Ambiguity is the norm; the “right” answers are often only right in retrospect. Some people leave; new ones join. People change their minds. Teams get reorganized. Conditions change. Incentives change. Learning to be effective under such conditions is not easy. We crave clarity and resolution, and often they’re not on offer. But learning to deal with ambiguity is essential to maturing as a professional designer.
Whenever I find myself in an ambiguous place, I take a step back to make an inventory of what I do know about the situation. (This will often take the form of a mind map or other such visual information dump. Stickies and a whiteboard are useful tools in this context.) I look for specific areas where I lack information. What has changed? What do I know I don’t know? How can I find out? What can I infer from the things I do know? (Of course, there’s also stuff I don’t know I don’t know. Knowing that offers some relief.) If other people are in the same situation with me, making these inventories together can help relieve some of the uncertainty, and remind me I’m not struggling alone.
Taking steps towards clarifying the situation is always preferable than letting it paralyze you. The process can even prompt you to reframe the problem you’re dealing with, bringing some degree of relief — if not closure.
Whenever I’m learning a new subject, I look for distinctions. These are concepts that are key to understanding the subject space, and which stand in opposition to each other. For example, the following distinctions are useful for understanding systems:
There are more, but tackling these few can help you gain a foothold on systems as a subject. Some of these pairs are characteristics of individual systems. (I.e., you can talk about whether a particular system is static or dynamic, open or closed, etc.) Others are useful in understanding the field as a whole. (I.e., the distinction between reductionism and holism speaks to the usefulness of systems thinking in general.)
Distinctions such as these allow us to understand abstract concepts more clearly, much as the interplay of shadows and lights help us see objects in the physical world. They turn up the contrast in otherwise difficult subjects, helping us see their edges. However, as we dive into dividing subjects up into opposites, we must remember they describe a whole, and complex subjects often contain self-contradictions that resist easy categorization. (Of course that, too, sets up a distinction to be examined.)
“What do you mean by ‘systems’?” This is the most common question I get when I tell someone I’m teaching a systems class. “System” is a concept so universally applicable that its meaning relies almost entirely on context; my interlocutor may be thinking something along the lines of, “I wonder if he means ‘computer systems’?” So I need to clarify. The class is about general systems theory; how all systems work — a broad subject indeed! (In our class we do focus a bit; we’re concerned with systems through the lens of interaction design.)
So what do we mean by ‘systems’ in this context? At its most basic, when we talk about a system we mean a collection of parts that relate to one another in particular ways so that the whole can serve a purpose. All systems — an automobile, a cat, a business — can be boiled down to this statement. As Donella Meadows pointed out, this means systems must have three kinds of things:
its constituent elements,
the interconnections between them, and
the function or purpose they serve when working together.
While it’s useful to break it down in this way, we need to keep reminding ourselves this is a holistic subject; we are less concerned with the constituent parts of systems than with the behavior they exhibit when they work together. (Russell Ackoff: “the performance of the whole is never the sum of the performance of the parts taken separately, but it’s the product of their interactions.”) We can’t study the whole without understanding its parts. That said, we need to constantly re-focus our perspective to take in the bigger picture if we are to stay true to the nature of the subject. This zooming in and out, while making abstract subjects understandable and engaging, are the primary challenges of teaching this subject.
Often the central artifact in my projects is a structure of some sort. This structure can often be represented hierarchically, as an outline. I aim for stability at the higher levels of the structure and flexibility at the lower ones.
For example, the syllabus for my systems course includes an outline of the themes for each class in the semester. Currently, it looks like this: