Tomorrow (3/21) I’ll be teaching a full-day workshop on the essentials you need to know to get started with information architecture. This workshop has a lot of content, but also includes hands-on exercises to give participants a taste of what it’s like to do this stuff.
On Thursday (3/22) I’ll be repeating the IA essentials material as a half-day workshop for the first cohort of IA Summit Scholars. I’m excited about this program and looking forward to meeting the students!
On Saturday (3/24) morning I’ll be hosting the first of two (yes two — by popular demand!) Polar Bear Yoga sessions. (Later that evening I’ll be embarrassing myself — as I do every year — at karaoke night. That is if my voice holds up; I’m currently getting over a cold.)
I hope to see you there. This will be my 12th Summit; it’s hard to believe I’ve been going to this conference for over a decade. The Summit is my favorite conference every year, and this year promises to be a good one! If you haven’t signed up already, I encourage you to register now.
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.
If you’ve been reading my blog for some time, you’ll know I often use the phrase “information environment.” This isn’t a word pair you’re likely to encounter in many other contexts, so I think it’s worthwhile to peg it down. The phrase is composed of two relatively common words: information and environment. You probably have ideas of what these are, but let’s first clarify what I mean by them here.
If you’re like most people, the word environment will evoke the rainforest, whales breaching the surface of the ocean, or smokestacks spewing filth into the atmosphere. In other words, ecological images. This is not surprising since we often see environment in phrases such as “protect the environment” or “save the environment” or “environmental pollution.”
The natural environment is certainly an example of what I mean by environment. However, I also mean it a bit more generally. When I say environment, I mean the surroundings of a system or organism, especially the aspects of those surroundings that influence the system’s or organism’s behavior. This latter condition is important; you could say your surroundings include all of the solar system, but the orbit of Jupiter has very little influence on your day-to-day actions. (Unless you’re into astrology, in which case I’d argue that the belief that the orbit of Jupiter influences your actions is what influences your actions, not the planet’s orbit per se. But I digress…)
It’s been a little over four years since my family and I moved to the SF Bay Area. Before the move, I reached out to my friends here to let them know I was coming and to explore collaborations. Chris Baum was one of the first to respond. I’d known Chris had started a design consultancy with two other partners; now he was inviting me to meet them. Long story short: we hit it off; I started consulting for them, and before long they invited me to join Futuredraft, their company.
In the past four years we all grew together in various ways and produced world-class work, adding great value to our clients. We also cemented life-long friendships. Alas, Futuredraft is now transitioning to a different phase, and my time with the company has come to an end. I’m grateful to Chris, Hans Krueger, and Brian O’Kelley for welcoming me to their little tribe. We remain good friends and may work together again at some point.
But now I’ve transitioned to a different phase myself: I’m consulting independently. Now that I’ve finished the manuscript for my new book (yay!), I’m exploring new opportunities to improve the information environments of our world. If your organization is looking to take design leadership to the next level, please take a look at how I can help and do get in touch. I’m excited to talk about what’s next!
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.
You hear about it all the time: an accomplished designer joins a large company to lead their design efforts, only to leave disillusioned and frustrated after a relatively short stint. These are smart people and great designers. They’ve come into the situation with the best intentions and have put their credibility on the line. This is not the outcome they wanted.
When you talk to them, they’ll tell you corporate politics ground them down, or that there’s too much inertia in the company, or that design isn’t as valued in the organization as they thought it would be, or that they’ve lost executive support. These things may all be true, but they’re all symptoms of a deeper issue: the leaders (and their teams) haven’t mastered the organization’s semantic environments.
Very few people are perfectly at ease. Most have something that worries them. Their kids’ education. Their job security. A big upcoming expense. A pending medical procedure. The success of a big project. You get the idea.
Their degree of agency over these things varies. Some they can’t do much about. (For example, their job could go away through no fault of their own.) But others — many, in fact — give them some agency. They can devote more time to that project, or skip that big night out so they can save money.
At some point, they’ll need to decide. How do they choose what to do? Experience plays a role; they’ve probably faced similar decision points in the past. But they must also understand the criteria that will allow them to choose one way or the other. They can inform themselves by asking friends, reading the news, or searching Google. Whatever the case, they need information.
They need more than this, though. They also need a causality model: a way to predict the repercussions of the decision. “If I do A, then Z is likely to result.” Their models mustn’t be perfect (they can’t be) — they only need offer some degree of confidence.
Leaders in organizations face many such choices, often with big stakes. These people are among the best decision-makers in the world. But creating solid models is very difficult in the complex contexts they work in. For example, a product feature may inadvertently create a national security problem. We call these unintended consequences, and they’re one of the things that keep leaders up at night.
In our complex world, we experience unintended consequences all the time. (Sometimes with disastrous results.) But there are ways we can improve our ability of predict outcomes with some degree of certainty. This is why you need to understand how systems work. Doing so allows you to learn how to model — have some control over — complex, volatile situations. It helps you sleep better.
If you say you’ve just been to the doctor, my default stance will be to believe you. But if you say you’ve been in an extraterrestrial vehicle where little gray beings ran medical tests on you, I’ll need more than your word. The claim you’re making (aliens!) is so far outside the bounds of what our everyday experience offers, that I’ll need additional proof. Grainy photographs won’t be enough.
Carl Sagan used to say that extraordinary claims require extraordinary evidence. This skeptical stance is healthy. You’re not saying “I’ll never believe this!”; you’re saying “I’m open to hearing you out — but this’d better be good!” Good decision-making calls for clarity; seeing things as they really are. This may be different from how we’re told they are. And not just by others: we can easily fool ourselves, crafting fantastic stories about the way things are.
As designers, we’re charged with conceiving different ways of doing things; different ways of being in the world. Our sketches and prototypes create simulations of what things would be like under different circumstances. The better we are at this, the more we are at risk of believing our alternate realities. This is one of the reasons why testing is so important: it helps provide validation for our hypothesis. The more outlandish they are, the more validation is needed. (The ultimate validation: a product or service that succeeds in the market.)
Every once in a while you’ll hear that the editors of the Oxford Dictionary have nominated a particular word to be the “word of the year.” (In 2017, it was youthquake.) Have you wondered what that’s about? Aren’t dictionaries the standard reference on the language? Why change them?
There are two approaches to curating language: what the pros call prescriptive and descriptive linguistics. The two names tell you what you need to know about the differences between them. The prescriptive folks argue that there are set rules to language and that those rules need to be obeyed if the coherency of the language is to be maintained. The descriptive folks aim to describe language as it’s actually used; they spot patterns, such as the most frequently used new words, and fold those patterns back into the ruleset. (That’s how youthquake happens.)
In both cases, the rules still matter. Language enables communication. We need to be on the same page if we are to communicate: I need to know what the word you’re using means given its context. That’s why we have dictionaries and grammars. So the question is not one of whether or not a ruleset exists, but how (and by whom) the ruleset is created and managed.
When you’re developing a design system, you’re establishing a set of rules others will use to create information environments; your team’s role is like that of the editors of a dictionary or a grammar. I’ve seen many such systems during my career. Some failed because of over-prescription (the rules were too inflexible) while others were too lax. The more successful ones were the ones who established the right mix between prescription and description.
Like the dictionary curators, you want to develop a general grammar and vocabulary but then leave space to accommodate actual usage. Because of this, developing a design system is less an exercise in traditional design than one in systems design. You need to put in place not just the initial vocabulary and grammar, but also the governance structures that will make it possible for the vocabulary and grammar to evolve. The system should also provide mechanisms to accommodate emergence: components and uses the core design team couldn’t have predicted.
There is no final deliverable in such a system; only an ever-evolving artifact that designers and product managers use to establish common ground. The yearly edition of the dictionary comes from a time when publishing was a process that resulted in a fixed artifact: a printed book. We need not be beholden to such constraints: A design system ought to be a dynamic, ever-evolving information environment. (A meta-information environment, since it will be used to produce other information environments; much as dictionaries and grammars are meta-books.)