Information Architecture as MacGuffin

SALLAH: Indy, you have no time. If you still want the ark, it is being loaded onto a truck for Cairo.
INDIANA: Truck? What truck?

This exchange from RAIDERS OF THE LOST ARK (1981) leads to one of the most thrilling car chases in movie history, in which our hero, Indiana Jones, fights his way onto the vehicle mentioned above. Onboard the truck is the Ark of the Covenant, which Nazis are trying to smuggle out of Egypt so their boss — Adolf Hitler — can use it to take over the world.

Sounds like a pretty important thing, right? Well, it isn’t. (Spoiler alert!) By the end of the movie, the crated ark is wheeled into a nondescript government warehouse packed with similar crates as far as the eye can see. The implication: this thing, which we’ve just spent a couple of hours obsessing about, will soon be forgotten — as it should be. You don’t want the audience to go home thinking about the implications of having something as powerful as the ark out and about in the world.

Continue reading

I Fight for the Balance

Hang around long enough with UX designers, and you’ll hear someone say it: “I’m an advocate for the users.” If the designer is especially nerdy, she’ll quote Tron: “I fight for the users.” She’ll go on to explain she’s the one who brings the users’ voice into “the room.” (A euphemism to describe the project team.)

This is an alluring stance for designers to take. (I know — I’ve said it myself earlier in my career.) For one thing, it sounds heroic. (Again, cue the image of Tron holding his disc over his head, ready to sacrifice himself for what is just and good and true.) For another, it clarifies designers’ position vis-a-vis the tough decisions ahead. Or so they think.

© Disney
© Disney

As compelling as it may be, “I fight for the user” is a misguided position for designers to adopt. Yes, it’s important to consider the needs and expectations of the people who use the organization’s products and services. But user needs aren’t the only forces that influence design.

The subtext to “I fight for the user” is that in this context (in “the room”) the user needs a feisty advocate — perhaps because others don’t care. This sets up a false duality: if I’m here for the user, you’re here for other reasons: making money, saving money, reducing call center volume, etc.

This framing isn’t healthy. Everyone should come to the room with the understanding that user needs will be important. It’s table stakes. If this attitude is not present from the start, then the designer should strive to bring it into the room — but as a way of building alignment with colleagues, not drawing distinctions between them.

So if designers aren’t in the room to “fight for the user,” what are they there for? Designers are there to move the project towards alignment between forces that could otherwise pull it apart. These forces include (but aren’t limited to):

  • Deadlines
  • Budgetary constraints
  • Regulatory/legal constraints
  • Production constraints
  • Business goals
  • Customer needs
  • User needs
  • Social needs

Striking the correct balance between these forces requires understanding their relative importance, which varies from project to project. (For example, healthcare projects have different regulatory constraints than those in entertainment.)

The team may get the initial balance wrong. That’s why we test prototypes in real-world conditions: We establish feedback loops that move the product or service towards ever-better fit with its context or market. Design’s role is in this process is making the possible tangible, progressively moving from abstraction to concreteness as the team iterates through increasingly better prototypes.

Eventually, the product or service will be in good enough shape to put into production. Design’s role then shifts to translating the intended direction into artifacts that guide the people who will build it. This requires understanding what developers need to do their work effectively. (It’s worth noting that this doesn’t need to​ happen in a strictly sequential “waterfall” manner.)

Shepherding this process calls for clarity and nuance. Good designers understand the relevance and directionality of all the forces shaping the project. User needs are an essential force, but not the only one. To pretend otherwise is to do a disservice to ourselves, our organizations, and design itself.

Bringing Others Into the New

Imagine you’re working on something new. I don’t mean new to you; I mean something truly new, as in, not done before. In the initial project stages you have an vague mess of ideas, some clearer than others. Incrementally, you make sense of these ideas; give them form.

Eventually, you’ll need to scale your efforts. If the project is come to life and grow, eventually you’ll need to recruit others. To do this, you must describe what you’re doing in terms they can understand. But how can they understand something that is new and messy? You must describe it in terms they already understand.

One way to go about it is by developing a high-level concept: a pithy statement that describes your idea by leveraging other ideas. For example:

  • ALIEN: “JAWS in a spaceship.”
  • HOOK: “What if Peter Pan grew up?”
  • LinkedIn: “Facebook for business”
  • YouTube: “Flickr for video”

None of these statements do full justice to these movies and platforms. But they’re remarkably easy to grasp and remember. In the parlance of the Heath brothers (whose book, Made to Stick includes a section on high-level concepts), these statements are sticky.

As long as the interlocutor knows what JAWS, Peter Pan, Facebook, and Flickr are, he or she will now have a way to dive into the subject. Once in, they can begin making the necessary distinctions that really set the idea apart. They will also be able to describe it to others, helping the idea spread.

Although high-level concepts are short, writing them isn’t easy. Doing so calls for tough decisions. What is this project really about? How does it compare to what’s gone before? Is this something people will get excited about? Boiling things down to such a statement can be hard, but it’s important that it happen. Doing so brings clarity and alignment. It also informs structural decisions at a point where projects are vague and ambiguous. Articulating a clear and compelling concept goes a long way to clarifying a project vision so others can bring it to life.

The Courage of Despair

Leadership calls for making tough choices. They’re often unpalatable; this is part of what makes them tough. People dislike change, especially when it requires trading predictable (even if less than ideal) outcomes for the unknown. But sometimes progress calls for a bold leap forward, regardless of how terrifying it seems. What to do?

In The Art of War (5th century B.C.), Sun Tzu wrote:

When you surround an army, leave an outlet free. This does not mean that the enemy is to be allowed to escape. The object is to make him believe that there is a road to safety, and thus prevent his fighting with the courage of despair.

The courage of despair. Archetypical image: Cortés’s ships burning off the coast of Veracruz; his men’s choices reduced to pushing into the unfamiliar or dying alone, marooned. A powerful situation that instigates coherent action; not a hectic, desperate flailing, but a single-minded drive towards a particular direction.

A tricky move to pull off. Cortés’s men probably hated him after he eliminated their path back to “safety.” How do you get people to continue following you after such a gesture? You craft a new identity. No longer a group of rag-tag mercenaries with disparate aims; we’re now a tribe hell-bent on survival. (Again, Sun Tzu: “When I let go of what I am, I become what I might be.”) For this to work, everyone must be committed to the new path — the leader included. After his order was carried out, Cortés, too, was stranded.

I’ve most often experienced the courage of despair in its opposite: the irresoluteness of confidence. A formerly successful team continues operating as before, even when their context has changed radically. Instead of facing the facts and starting in a bold new direction, the leader hedges his or her bets. Unable to grasp — and act on — the urgency of the situation, the team continues in “business-as-usual” mode; their options gradually whittle away; their former cash cows become emaciated. When the moment of reckoning arrives, they’re unprepared. Catastrophe ensues. (I’m ashamed to admit: I’ve been the waffling leader.)

There’s no fighting “as if” your life depended on it. It either does, or it doesn’t. In today’s world, most leaders will not be called on to turn choices into literal life-or-death scenarios. But fostering courage and action will sometimes call for closing off comfortable choices in favor of moving towards new, unfamiliar directions.

Dealing With Organizational Politics

For some kinds of problems, it’s essential that you think through what you’re doing before you work out how you’re going to do it. Common sense, right? Unfortunately, it’s not the norm. Too many designers still start projects by formally exploring directions before they’ve nailed down answers to key questions:

  • What distinctions will this solution impose on the situation?
  • How do those distinctions help/hinder the path to user satisfaction?
  • How do the organization’s governance structures affect our ability to create distinctions that support the user’s journey?

This last question is the most challenging for designers since it requires that we delve into territory many of us would rather leave unexplored: organizational politics.

Political struggles result when individual groups try to further their own agendas while serving the organization’s overall goals. Groups (and their leaders) compete and cooperate with other groups for resources and attention. Through the choices they make, they try to position themselves to achieve influence and power. Given enough scale and resources, all organizations exhibit some of these power dynamics. In some cases — but not all — these struggles can become toxic, affecting the performance of the organization and the people in it.

Many designers complain about having to deal with political forces. But dealing with politics is not only part of the job; it’s also a sign of maturity: The point of design is effecting change, and the only designers who don’t have to deal with politics are the ones who aren’t causing real change in their organizations.

Note this doesn’t mean designers should merrily go along with highly dysfunctional situations. Life is too short to deal with that sort of thing. But it’s important to acknowledge that design can disambiguate complex situations, leading to clarity and better decision-making for everyone involved. Understanding how power dynamics work — and embracing the reality of politics — is essential for designers who seek to effect real change in their organizations.

The Role of Design in Strategic Decision-making

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

— Steve Jobs

Strategy calls for making choices. That means saying “yes” to some things and “no” to others. The latter is the harder of the two.

Leaders often face options that seem equally compelling but are mutually exclusive; choosing one means forgoing the other. Economists talk about the opportunity cost of a decision: the potential value we give up when we choose one option over another. Let’s say you have enough budget to invest in one of two promising projects. The opportunity cost of choosing project A is whatever value project B would’ve generated. If it turns out B’s value would’ve been higher than​ A’s, you made a poor choice.

How do you know?

Continue reading

Design Strategy Inside Out

Today, design is seen as a key function inside many organizations. For recently-minted designers, this statement may seem trite. “Of course design matters,” they will wonder. “Why wouldn’t it have a key role in the creation of products and services?” Well, design wasn’t always as central to business as it is today. Many people (including me) attribute design’s current prominence to Apple’s resuscitation in the late 1990s, its emergence from the ashes, and eventual domination of the tech market and beyond.

Wired magazine cover from June 1997.

Design played a central role in Apple’s comeback, and the business press gave it its due. But before this, many people inside organizations saw design as being in service to either marketing or surface decoration. One result of Apple’s back-from-the-dead story is that many large organizations today value design — and not just in the superficial sense of making things more attractive, but in the deeper sense of design as engine of coherence, engagement, innovation, and brand loyalty.

Continue reading

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

Fielding Ambiguity

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.