Teaching

How to Understand a Complex Subject

| Jorge Arango

Sometimes you need to understand a complex subject. When first getting into it, you’re faced lots of new concepts and ideas, unfamiliar language, unexpected connections between terms, etc. There’s lots of information to digest. Where do you start? How do you make sense of it all?

Understanding complex subjects is a meta-skill: a skill that helps you become better at acquiring other skills. When you hone your ability to understand, learning new things becomes easier. Improving your sense-making skills is a powerful boost for your effectiveness.

Concept mapping is the best practice I’ve found for making sense of complex subjects. A concept map is a visual representation of the relationships between concepts that affect a particular problem or domain. In contrast to a linear exposition of the subject, a concept map lets you pick the starting point for your investigation and allows you to see details in the context of the big picture. A well-crafted map achieves the goal Richard Saul Wurman laid out for information architects: to help others find their own paths to knowledge.

The best conceptual mapper I know is Hugh Dubberly. The Dubberly Design Office website has an entire section dedicated to showcasing their beautiful and insightful maps. These maps are inspiring — and also a bit intimidating. But concept maps mustn’t be elaborate or polished to be valuable.

A post on the DDO blog shows you how to create your own concept maps. I use this approach with my students and in my professional work; it’s the best way I’ve found to understand complex subjects.

The Role of Paper in Learning

| Jorge Arango

How do you learn a new subject? Let’s say you’re starting work on a new project, one where you have expertise in the craft but not the domain. You’ll be working alongside subject matter experts. Their time is limited; you don’t want to waste it by asking lots of newbie questions. It’s up to you to come up to speed fast so you can ask relevant questions and help structure the problem.

As a strategic designer, I find myself in this situation often. For example, a few years ago I worked on the design of a system that was meant to be used by neurosurgeons and radiologists. While I’d designed user interfaces for complex systems before, I didn’t know much about neurology. Working in this space required that I get up to speed quickly on a complicated subject matter. (No “it ain’t brain surgery!” jokes on this project!)

Over the years I’ve developed techniques for learning that work for me. I’ve written before about the three-stage model I use. To recap: when learning a new subject, I aim to 1) contextualize it, 2) draw out the distinctions in it, and 3) explore its implications. I strive to make each stage actionable: to make things with the new information I’m learning.

What kinds of things? It depends on the stage of the process I’m in. In the very early stages, it’s mostly scribbles, sketches, and various notes-to-self. Further on in the process, I look to share with others — especially with people who know the subject matter. In both cases, I’m looking to establish a feedback loop. Seeing the ideas out in the world changes my relation to them. I’m reminded of the tagline on Field Notes notebooks: “I’m not writing it down to remember it later, I’m writing it down to remember it now.” Spot-on. The act of putting pen to paper changes my relationship to the idea; the act of articulating it nudges me to give it structure and coherence.

I deliberately chose the phrase “putting pen to paper;” this process doesn’t work as well for me with digital tools. I’ve been experimenting for years with digital sketchbooks, but keep coming back to pen-and-paper for speed, reliability, and ease-of-use. That said, digital tools play an essential role. My (continuously evolving) learning ecosystem includes software like OneNote, Ulysses, OmniFocus, and Tinderbox. Recently I’ve also started experimenting with DevonThink. These tools all serve specific needs and do things that paper can’t do.

There’s lots of overlap between these tools, so why have so many of them? It’s tempting to want to cut down the ecosystem to as few tools as possible. But putting everything into a single tool means sacrificing important functionality; the ones that do lots of things don’t do any one of them as well as dedicated tools. For example, OneNote, Tinderbox, and DevonThink can capture reminders, but none of them do it as well as OmniFocus, which is designed for that purpose. (Having OS-level, cross-app search functionality such as macOS’s Spotlight is a boon, since it means not having to remember which app you put stuff into.)

A paper notebook could be the ultimate “does everything” tool. People have been taking notes on paper for many hundreds of years. There are lots of frameworks around that allow you to use plain paper to track commitments (e.g., bullet journals), separate signal from noise (e.g., Cornell notes), etc. Paper is super flexible, so there’s always the temptation to do more with it. But paper is far from perfect for some learning activities. For example, capturing lots of long texts and finding patterns in them (what I’m using DevonThink for) is best done with digital tools.

While the form of my learning ecosystem keeps evolving, it’s increasingly clear what role my paper sketchbook plays: It’s a scratchpad where raw thoughts and ideas emerge. It’s not for capturing long texts. It’s not for sharing with others — not even with future me (i.e., “to remember it later.”) Instead, it’s an extension of my mind; a sandbox where I shape for myself — thus internalizing — the things I’m learning.

In practice, this entails jumping back-and-forth between digital tools and paper. I once aspired to consolidate these steps into a “smart sketchbook” (see here and here) that would allow me to eschew paper. However, I increasingly value the role my physical sketchbook plays in my learning ecosystem. Its limitations are an advantage: using it requires a shift in modality that keeps ideas flowing, vibrant, and malleable.

A Model for Teaching (and Learning)

| Jorge Arango

Even if you’re not a professional educator, sometimes you must teach others. Perhaps someone has joined your team and needs inducting into your project, or a child asks you about the meaning of some obscure term, or you’re called on to tell an audience about your company. Whatever the case, many of us often find ourselves having to introduce others to ideas that are new to them.

Over time, I’ve found a pattern for teaching that works well for me. It consists of four steps:

  1. Contextualize
  2. Draw out distinctions
  3. Explore implications
  4. Make it actionable

Continue reading →

Give Priority to Old Sources

| Jorge Arango

Acquire the habit of attending carefully to what is being said by another, and of entering, so far as possible, into the mind of the speaker.

Advice from the latest designer advocating empathy? The newest self-help sales craze? No, a snippet from the Meditations of Marcus Aurelius, written in the first century​​​ B.C.E. Old books can be useful. Sometimes, more useful than the “latest greatest.”

According to Forbes, there are between 600,000 to 1,000,000 new books published every year in the U.S. alone. There are also other media competing for your attention: Twitter, Facebook, YouTube, news websites, blogs, TV, etc. That’s a lot of content, and you have limited time. How do you know what to prioritize?

Whenever I’m faced with multiple choices for a particular subject, I gravitate towards older sources. Recently I’ve been reading about strategy and consulting. There are lots of books in these categories. Some have been around longer than others. Those are the ones I start with.

Why? Because the market weeds out the less useful ones over time. Among the countless books being published this year, only a few will still be in print fifty years from now. That’s because the ideas in those books have proven useful to people from multiple generations. They’re probably useful to you too. When given a choice, prioritize these older sources. If you can see beyond their sometimes stale examples and illustrations, you’ll find much that is timeless and valuable.

(I write this with conflicted feelings since I have a book coming out soon. But I’ve aimed for it to be useful in the long run. I’m also honored to have contributed to another book that has been in through four editions over twenty years of continuous publication.)

The Abstraction Bell

| Jorge Arango

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

| Jorge Arango

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

| Jorge Arango

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

Bringing Systems to Life in Fort Mason

| Jorge Arango

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.

Fielding Ambiguity

| Jorge Arango

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.