The Abstraction Bell

Most people don’t like abstractions. You start telling them about models and concepts and hierarchical constructs and their eyes glaze over; they look past you, wondering when you’re gonna get to the good stuff. (Or, more likely, about lunch.) This is a problem for people whose work requires dealing with and communicating abstract concepts, like information architects.

One way to deal with this is to own it: You tell the other person, “yes, this is abstract stuff — but that’s alright.” Doing so won’t relieve your interlocutor from his or her anxiety, but at least it lets them know you acknowledge this may be uncomfortable ground to cover; that it’s ok for them to ask for clarification.

When you’re teaching this stuff, abstraction comes up all the time. In workshop settings, especially, participants may not be in the mindset to deal effectively with abstraction. In order to own it with these students, I’ve started using an “abstraction bell”: I (literally) ring a bell every time I start talking in particularly abstract terms. (I’m using a meditation timer on my phone as the “bell.”) This is a fun way to remind students that I’m aware of the fact we’re venturing into abstract territory. It permits them to ask questions and allows them to relax in the knowledge that all may not be immediately clear.

Of course, it’s always preferable to make ideas more tangible. But that’s not always possible. In those cases, we’re saved by the bell.

Teaching IA in Chicago

I’ll be in Chicago over the next few days for the 18th annual Information Architecture Summit. This year I’ll be leading a few sessions:

  • 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.)
  • On Sunday (2/25) I’ll be hosting the second Polar Bear Yoga session.

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.

Mastering Systems Diagrams

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.

Henri Cartier-Bresson—one of the greatest photographers ever—worked with cameras that are primitive compared to today’s tools. Image: Fondation Henri Cartier-Bresson (via Phaidon)

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.

What is an Information Environment?

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…)

Continue reading

Two Phase Transitions

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!

Bringing Systems to Life in Fort Mason

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.

We visited The Interval, home of the Long Now Foundation. There, students learned about pace layers (Otto — The Interval’s chalkboard robot — drew Stewart Brand’s famous diagram for us!), Geneva mechanisms (over an amazing model of the 10,000-Year Clock’s chime generator!), compensating for variance over time (examining a model of the Clock’s Equation of Time Cam!), orreries, the properties of tungsten, and more. (I’m grateful to Nick Brysiewicz and the Long Now team for sharing their space and knowledge with us.)

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.

The Value of Mapping Semantic Environments

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.

Continue reading

What Keeps You Up at Night?

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.

Extraordinary Evidence


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.)