The Power of Constraints

I learned one of the most important lessons in my career during my first semester in architecture school: there is great power in exploring the constraints of a design project.

Jeff, the instructor who was leading my very first design studio class, asked us to create a three-dimensional composition using a limited number of elements: wood dowels, foam core planes, wire, etc. The constraints seemed very limiting. Still, this was one of the very first things we’d been asked to design and my fellow students and I aimed to make them “cool.”

When we came together to share what we’d done, all of the compositions looked oddly familiar. It seems we’d all assumed we were supposed to be modeling spaces; all the compositions featured elements that looked like scaled walls and columns. Jeff asked us why we hadn’t considered using dowels with a diameter bigger than their height, or very thick foam core. He hadn’t specified any of these things; we’d assumed they were supposed to be a certain way.

Jeff explained there is a great deal of freedom in constraints: instead of facing the intimidating challenge of a completely blank slate, you’re tasked with exploring the boundaries of a limited domain. I’d never heard this idea expressed like this before, and it blew my mind. I spent the rest of my career as an architecture student exploring the boundaries of projects, and finding great joy in doing so. (I still do.)

Some of my favorite work comes from smart people exploring the constraints of a problem domain. Two examples, in particular,​ come to mind when I think about this.

The first is the icon system Susan Kare designed for the first Macintosh computer. Kare was dealing with incredibly limited constraints: a 512 × 342-pixel screen that could only display 1-bit color. These constraints meant icons needed to be relatively small, and could only use two colors: black and white. The clarity and charm that many people associate with the Macintosh come directly from the beautiful and subtle balance that Kare struck with her icon designs for the system:

Image: Fast Company https://www.fastcodesign.com/3043312/moma-recognizes-susan-kare-the-designer-of-the-macintoshs-original-icons
Image: Fast Company

Kare went on to design other icon sets for computer systems with more colors and higher resolution graphics, but they don’t have the power, simplicity, and personality that her original Mac icons do. I attribute this to the constraints she faced in the project.

The second example comes from the work of the musician and producer Brian Eno. In 1994, Microsoft asked Eno to design the startup sound for its then-new operating system, Windows 95. This OS was a great hit when it was released, so many people got unwittingly exposed to Eno’s work. Here it is, in case you haven’t heard it:

The commission for this piece came with a very interesting constraint that liberated Eno. He relates what happened in an interview:

The idea came up at the time when I was completely bereft of ideas. I’d been working on my own music for a while and was quite lost, actually. And I really appreciated someone coming along and saying, “Here’s a specific problem — solve it.”

The thing from the agency said, “We want a piece of music that is inspiring, universal, blah- blah, da-da-da, optimistic, futuristic, sentimental, emotional,” this whole list of adjectives, and then at the bottom it said “and it must be 3 1/4 seconds long.”

I thought this was so funny and an amazing thought to actually try to make a little piece of music. It’s like making a tiny little jewel.

In fact, I made 84 pieces. I got completely into this world of tiny, tiny little pieces of music. I was so sensitive to microseconds at the end of this that it really broke a logjam in my own work. Then when I’d finished that and I went back to working with pieces that were like three minutes long, it seemed like oceans of time.

I’ve had similar experiences, where a project’s constraints make me see it (and the rest of my work) in a different light, triggering a flurry of creative activity. Every time I encounter this situation, I thank Jeff for teaching me that lesson so many years ago: There is incredible power in constraints. Don’t fight them; embrace them.

Synchronizing the Pace of Communications

I was once a director in a team responsible for the online presence of a large company. At one point, the VP who oversaw our department had us take Myers-Briggs profile tests. I wasn’t sold on the profiles (and still aren’t), but I did learn something which has proven useful throughout my life: that different people have different paces when communicating. Specifically, some people process what they hear very fast and respond immediately, while others take more time. (This doesn’t imply these people are smarter or better than the others — they’re just different.)

When the two types interact, the differences in their paces can cause all sorts of trouble. People with very short feedback cycles become impatient when interacting with people who take longer. Conversely, people who take longer can feel overwhelmed and ignored by people with fast paces. Being aware of these differences can go a long way to improving communications, since each party can adjust their interventions to improve the flow of ideas and ensure the other is being heard.

Teams, too, have communication paces. Let’s say you’re a member of a company’s design team. You and your fellow designers are focused on different aspects of a product or service. You come together periodically to “synch up” with each other (either remotely or in person); perhaps it’s a Monday morning meeting where everyone shares what they’ve done and learned, the challenges they’re facing, etc. Eventually, ​you establish a rhythm of work dictated by these weekly meetings; you expect to see and produce progress at this pace.

Now imagine you’re asked to work with a group of stakeholders in another department. The folks on this team don’t have weekly check-in meetings; they’re on a two-week cycle. As a result of this difference in schedules, your requests for feedback take longer than you expect — sometimes weeks longer. Eventually, you become frustrated and perhaps even start suspecting your counterparts’ motives and/or competence.

It’s easier to adjust your own pace than those of other people. Asking questions such as, “When do you need this by?” and “How soon can I hear back from you with an answer?” can seem trivial, but managing expectations around communications is essential. When working with folks on a long-term basis, be on the lookout for patterns. How soon do they respond with information that moves the project forward? How much leeway do they give when making requests?

Knowing your interlocutors’ pacing can help make you a more effective communicator. Determining the right pace calls for paying attention to how and when they’re responding and having the self-awareness to know different people — and teams — have different communication needs and expectations.

What’s the Purpose of Design Artifacts?

At a high level, the purpose of design artifacts is always the same: to communicate intent. However, audiences for artifacts vary widely, and they all want different things out of them. Hence, we have many different approaches to documenting design which vary in scope and degree of fidelity.

Audiences can include:

  • Stakeholders
  • The stakeholders’ bosses
  • Customers (who will be testing the system)
  • Developers
  • Other members of the design team
  • The designer herself

Purposes can include:

  • Understanding the general direction of the system
  • Exploring structural directions
  • Exploring possible interaction mechanisms
  • Exploring visual directions
  • Understanding decision-making
  • Providing construction guidance to developers
  • Testing with customers

Designers need to understand the needs of the audience(s) that will be using their design artifacts, and which artifacts work best for particular needs. Artifacts suited for communicating visual directions do little to communicate structural directions, and vice-versa, while those that provide construction guidance are not best for justifying decisions — or at least they don’t if they’re any good. A stakeholder may have little use for construction documents other than to know they exist and can be used to build the system. On the other hand, this same stakeholder may need documents that justify the reasoning behind design directions, something that would be of little use to users of the system.

It’s easy for us to fall into the trap of believing that artifacts are the design. I’ve seen situations where stakeholders specify upfront the types and quantity of “deliverables” for a design project, with no regard for what they will be used for. Designers willingly comply because they, too, tend to measure their progress based on the wireframes, sketches, prototypes or whatever else they’ve produced. This is a mistake. Artifacts are communication tools. They’re a sort of language we employ when communicating intent; a means to create ​a feedback loop between the design team and others in the world — which is to say, a means for bringing others into the design team. Using the wrong feedback loop with the wrong audience at the wrong time can do more harm than good.

Knowing which type of artifact is most appropriate to a particular audience for a specific purpose requires two-way agreement: both parties must negotiate the protocol. Ask people what they need, and know when you’re called to suggest alternatives. After you find out what works best for the people involved, you can communicate intent in ways that make it useful for the situation at hand.

Vision Before Refinement

All projects start with a vision — even if it’s just a hunch — about a future state of the world that’s different from the current state. As a designer, one of your responsibilities is to help clarify and express this vision as something tangible.

I often read about teams starting by creating a first version of the product meant to test assumptions, which they then iterate on it as they get feedback from users. But how does the team know which are the truly important assumptions to test if they don’t know what they’re ultimately working towards?

I sense every project starts with these hunches of what it’ll be — but the people driving them often skip the step of clarifying and articulating what the vision is. Visioning can be fuzzy stuff — hard to do for teams who what tangible results as soon as possible.

Clarifying the vision upfront will lead them to ask hard questions, such as “why does the world need another x”? Peruse any of the major app stores: While there are a few excellent products out there, the majority of stuff is either not very good or redundant. Articulating the vision can help you see your product more clearly vis-a-vis the market, and focus the team on the key features that will differentiate it. What’s the point of refining something that’s not worth building in the first place?

Thinking and Feeling

The most intense architectural experience I’ve had was a visit to the chapel of Notre Dame du Haut in Ronchamp, France. It’s a small, peculiar building designed by Le Corbusier and built in 1954.

Image selbst fotografiert, via Wikipedia (https://de.wikipedia.org/wiki/Datei:Notre_Dame_du_Haut(ws).jpg)
Image by selbst fotografiert, via Wikipedia

I was in my early twenties when I visited Ronchamp. As an architecture student, I’d seen many photos of the place, created a detailed pencil rendering of the building, and built a plaster model with classmates. Which is to say, this building was not unfamiliar to me.

Still, when I walked through its unusual pivoting door, I was overcome with emotion. Something about the place — the light coming in through the stained glass windows, the texture of the walls, its peculiar acoustic quality, the shape of the roof, the sparseness of furnishings and, perhaps, the fact I hadn’t slept much to get there — conspired to overwhelm me. I wept.

Image by Jean-Pierre Dalbéra, via Flickr (https://www.flickr.com/photos/dalbera/29030425846)
Image by Jean-Pierre Dalbéra, via Flickr

At the risk of sounding trite, this building connected me with something eternal. It’s a place out of time: a modern work that is also entirely primal. I spent the rest of the morning walking in and around the building, in a daze. I didn’t sketch much.

I’ve had other emotional reactions to being in architecture. The Boboli Gardens in Florence. The Salk Center in La Jolla, California. Rockefeller Center in New York. None have been as intense as what I felt that day in Ronchamp.

Places like these don’t move us because of what they represent; they act on us at a level below thinking.

I’ve never had a comparable experience in a website or app. We experience information environments through language — that is, intellectually. We’re seldom moved by our experiences in them. Sure, we may have been angered by something someone’s written on Facebook, or driven to hysterics over a cat GIF. But those are not reactions to Facebook-as-place; they’re reactions to things that happened in Facebook. A key difference.

Christina Wodtke has written about poetics as a critical component of design. We don’t focus enough on this aspect of our work. When designing websites and apps, we mostly deploy language for pragmatic ends: to help people find and understand things. This constrains our ability to elicit emotional responses. Or does it? Notre Dame du Haut fulfills all of its pragmatic requirements as a building even as (or perhaps because) it moves us emotionally.

Tools of the UX Trade

The tools we use when we design have an important influence in the work we produce. Conversely, sometimes the work we want to do can’t be carried out with the tools we have. This nudges us to either look to other fields for inspiration or invent new tools altogether.

As a child, the architect Frank Gehry was fascinated with fish. This fascination carried through to his work. In the 1980s, Gehry started producing fish-shaped lamps, and eventually won a contract to produce a large fish-shaped sculpture for the 1992 Olympic Games in Barcelona.

Sculpture by Frank Gehry, Barcelona (1992.) Image by Till Niermann, CC BY-SA 3.0 via Wikimedia. (https://commons.m.wikimedia.org/wiki/File:Barcelona_Gehry_fish.jpg)
Sculpture by Frank Gehry, Barcelona (1992.) Image by Till Niermann, CC BY-SA 3.0 via Wikimedia.

Gehry’s team needed to figure out how the fish would be built. Traditional architectural drawings are best when describing buildings composed of flat planes and volumes, but this structure’s undulating surfaces were anything but. The standard tools of trade trade weren’t going to cut it.

One of Gehry’s collaborators suggested they look at a software tool called CATIA, which had been developed by French aerospace firm Dassault Systems for designing aircraft. CATIA allowed Gehry’s team to delegate the complex calculations to computers, and made the fish structure a reality.

CATIA also opened new possibilities for the firm — and the field of architecture more broadly. Buildings such as the Bilbao Guggenheim Museum and the Walt Disney Concert Hall in Los Angeles wouldn’t have been possible to design and build using traditional tools. Introducing new tools into the mix made a new type of building possible, and the field of architecture hasn’t been the same since.

Walt Disney Concert Hall in L.A., by Frank Gehry. Image by Visitor7, CC BY-SA 3.0 via Wikimedia. (https://commons.m.wikimedia.org/wiki/File:Walt_Disney_Concert_Hall-1.jpg)
Walt Disney Concert Hall in L.A., by Frank Gehry. Image by Visitor7, CC BY-SA 3.0 via Wikimedia.

When I look at the tools UX designers use, I mostly see software aimed at designing screen-based user interfaces. Applications such as Photoshop, Illustrator, and Sketch are excellent at rendering forms on flat screens, but not much more than that. This constrains possibilities; as the cliche says, if all you have is a hammer, everything starts to look like a nail… and these apps are all hammers.

We also lack tools for exploring the semantic structures and relationships that underpin information environments. The closest we come is whiteboards and diagramming apps such as Visio and OmniGraffle. I’ve met many taxonomists whose primary tool is Excel; software designed for manipulating numbers!

There are clear gaps in this space. It’s surprising, given that the focus of UX design is often software itself. Why haven’t we produced tools suited to the needs of designing information environments? Is it a matter of the market not being big enough? Or do they exist and I’m just not aware of them? What tools from other fields could we adopt to meet our needs?

Drawing to Think

My friend Christina Wodtke recently published a book called Pencil Me In. It’s aimed at encouraging “people who can’t draw” to draw more, especially in a business context. (You should get it even if you don’t think you fit that description — it’s really for everyone.) She kindly gave me a copy of the book autographed with the following directive:

Never stop drawing to think!

I love that. (Thanks, Christina!)

People assume the main reason to draw is so they can communicate something to someone. “A picture is worth a thousand words,” they’ve been told. So they draw — sometimes reluctantly.

Drawing to think is in one sense drawing to communicate. The difference is you’re communicating with an audience of one: you. You’re getting the abstractions out of your head and onto a medium where they can be made tangible, where you can examine them and iterate on them. A shitty first draft.

When you draw to think, your pencil and paper and hand and eyes and nervous system become one thing working in concert. You create a feedback loop: “This one goes too far. Let’s try this… Not far enough. I see what happened there. Wait. What if I did this to it? What would that do to the rest of the composition? Etc.”

Drawing to think has been central to my way of working for a long time. I’ve explored various ways of doing it, including using computers and iPads. These days I mostly draw on paper using black ink. When the time comes to share the ideas with others, I switch to the iPad to sketch something more polished.

Polished drawings are good when communicating with others, but rough ones are better for thinking. Thinking requires iteration: one more drawing… one more drawing… one more drawing. That calls for speed, and quick is rough, at least for me. That’s ok! This audience-of-one can see through the mess.

You may be familiar with Philippe Starck’s Juicy Salif citrus squeezer:

Image: alessi.com
Image: Alessi

It’s a beautiful object (although I’ve heard it’s not a very functional citrus squeezer.) Juicy Salif looks organic, as though it emerged from the natural world somehow. It didn’t — it emerged from a feedback loop between Starck and a placemat in a pizzeria on the Amalfi coast. Here’s a photo of the placemat:

Image: hivemodern.com
Image: Hive

Look at all those little sketches! This is a picture of Starck’s mind exploring the problem space for this artifact. It’s not a record of his thinking process — it’s where the thinking happened. An important distinction. (Check out Andy Clark’s book Supersizing the Mind for a deeper description of how these feedback loops work.)

Drawing to think is central to design. If you don’t do it already, I strongly encourage you to establish the practice. Christina’s book is a great place to start. That said, you don’t need much instruction — just get the feedback loop going in whatever way works best for you. It’ll help you think better.

The Illusion of Precision

“We are searching for some kind of harmony between two intangibles: a form which we have not yet designed and a context which we cannot properly describe.”

— Christopher Alexander

For me, the hardest part of any project is the beginning, when I have nothing yet but good intentions. When writing a post such as this one, I usually start in front of a (mostly) blank screen with a blinking cursor that taunts me: “Go — Go — Go — Go — …” Go! But what? No, that’s stupid. What about this? No, that’s not grammatically correct. “Go — Go — Go — Go –…” Sigh. Eventually, something clicks: I start typing, and words start flowing. Relief! Invariably, the result is what is technically known as a “shitty first draft.”

Shitty first drafts are very important to a project, whether it be a blog post or the information architecture of a website. It’s much easier to improve something that exists than to conjure it up in the first place. The simple act of attempting to articulate a form reveals insights into the context you’re trying to address. The first draft may be completely off the mark, but at least now you’ve got something to react to. You can get a sense of how the form measures up to the context so the next form will get a little closer as your understanding grows. It’s a virtuous cycle, and it takes time.

Although getting to the first draft is always intimidating, at least I’m aware of the process; I expect this step and know the first thing I make won’t be definitive. This helps me relax so I can get the ideas out of my head and onto a tangible form I can test.

Doing this by myself is not necessarily easy, but doing with other people is much more difficult. For one thing, we all tend to be protective of our self-identity. What if they think this is stupid? Will I lose credibility? Will my reputation suffer? For another, the tools we use — especially in digital design — can encourage us to jump to higher levels of fidelity sooner than necessary in the process. I have no problems understanding my quick Sharpie sketches, but stakeholders often want to see hard-lined documents. Also, much of the work in information architecture revolves around lists of words. These are easier to produce and iterate using computers than pen and paper, but putting them in an Excel spreadsheet or an OmniGraffle diagram anoints them with a level of firmness that can be misleading.

The result is a cognitive bias I call the illusion of precision. This is when something looks so polished that it leads you to believe it’s been thought through, when it actually hasn’t. It’s not a final proposal, only a first stab at the form that will address the context. Unfortunately, the way it’s communicated leads people to misinterpret it as more stable than it actually is. The illusion of precision is dangerous because it can lead people to treat shitty first drafts as though they’re something more than that. An example of this is when a stakeholder reacts to a wireframe by commenting on the font selection. The artifact is so rich it causes them miss the point entirely.

Still, you must start somewhere. First drafts will be rough, but they must still convey meaning. The right level of fidelity will depend on what the thing being designed is and the needs of the teams involved. As a design leader, it’s important that you set expectations clearly, so people don’t assume they’re looking at something more polished than it’s supposed to be.

Deliverables

I once had a summer job working for an established architect. His office had a closet full of old sets of rolled up construction documents, and my first task was to organize them. This required that I examine each roll one by one. I found many drawings for buildings I was familiar with, but the most interesting thing I found was plans for an addition to a house designed by the office of Frank Lloyd Wright. As a young architecture student, I was enthralled. Frank Lloyd Wright! But nobody else cared. The documents were crumbling, forgotten in storage.

This is as it should be. The map is not the territory and the plans are not the house. A set of technical drawings for a house may be of historical and cultural interest, but it’s far less interesting and useful than the actual house they describe. When the crew is on the job site swinging sledgehammers and pouring concrete, these documents are critical. Once the structure is built, their value rapidly declines.

It’s been many years since I worked as an architect (of buildings), but in my brief experience, I never saw a client ask to specify the form documents should take. Clients understood they were hiring the architect to design them a house, an office, an abattoir. Never once did they confuse the drawings with the finished product, nor did they ask the architect to price the project based on them.

Often, one of the first conversations that happens when starting on the design of an information environment is the one around deliverables. The client has many questions. What documents will you be producing? What form will they take? What do they look like? (Show me!) How many will there be? And so on. Although it’s not that frequent anymore, I’ve even seen RFPs that ask designers to price the project based on how many of these documents will be created.

I don’t like this word, “deliverables.” It implies these artifacts are the product we’re being asked to deliver. They’re not. We’re designing an information environment. That is the product. Wireframes, sitemaps, conceptual models, etc. are communications tools that help designers, stakeholders, and developers establish a generative dialog towards producing the built environment.

In an emerging field, such as our own, there will be many questions about the artifacts we use to communicate intent. This is understandable, and we need to address those questions. But we also need to make sure we’ve framed the conversation, so tools and means do not become the focus of the engagement. The focus should always be on the goal: the quality of the environment we’re designing together. “Deliverables” are the means to get there, not the destination.