Extraordinary Evidence

Photo: independent.co.uk
Photo: independent.co.uk

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

Design Systems and Emergence

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

Design and Implementation Trade-offs

A couple of days ago I wrote about how important it is for designers to know their materials. The material for interaction designers is code, so a baseline understanding of what code can and can’t do is essential for designers to be effective.

I learned this principle in one of my favorite books: The Art of Computer Game Design, by Chris Crawford (Osborne/McGraw Hill, 1984). Crawford was one of the early Atari game designers/implementors. (I use the slash because the distinction wasn’t as clearly drawn then as it is now.) His book lists seven design precepts for computer games. The seventh of these is titled “Maintain Unity of Design Effort,” and includes the following passage:

Games must be designed, but computers are programmed. Both skills are rare and difficult to acquire, and their combination in one person is rarer still. For this reason, many people have attempted to form design teams consisting of a nontechnical game designer and a nonartistic programmer. This system would work if either programming or game design were a straightforward process requiring few judicious trade-offs. The fact is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts is rather like handcuffing a pole-vaulter to a high jumper; the resultant disaster is the inevitable result of their conflicting styles.

More specifically, the designer/programmer team is bound to fail because the design will make unrealistic demands on the programmer while failing to recognize golden opportunities arising during programming.

Crawford illustrates this by using a couple of examples from his career. One that’s stuck with me comes from the development of the game EASTERN FRONT 1941, a war game for the early Atari 8-bit computers. While he was programming the game (which he’d also designed), Crawford spotted an opportunity: a simple addition to its calendar routines would allow color register values to change as game time progressed. This allowed the color of trees to change to reflect the seasons. A minor detail for sure, but one that added depth to the experience. (Keep in mind that programming for these early computers meant always optimizing for limited memory. This minor change came at the expense of only 24 bytes of computer memory; a “cost-effective improvement” in Crawford’s words.)

Software development is much less painful today than it was in the late 1970s and early 1980s. Still, limited budgets and timeframes call for trade-offs. Knowing where the opportunities and constraints are helps when you’re called to decide what to include and exclude in the work.

Know Your Materials

One of the main things I learned when I learned to paint with oils is how deeply the characteristics of the materials involved — canvas, gesso, oil, pigments, solvents — influence the form of the work. As a painter, you think differently when working with oils than when working with acrylics or watercolors.

The same is true for any creative endeavor. Whether you’re designing a new evening gown or the landscaping for a vacation home, your thinking about the subject (and hence the form of the final output) will be deeply informed by how well you understand the constraints and possibilities afforded by the materials.

The more mastery you have over the medium, the more effective you’ll be. Mastery calls for more than conceptual knowledge. Conceptual (or “book”) learning is not enough; you need hands-on time with the object of your design to understand what it can and can’t do.

One of the perennial discussions among UX design practitioners is whether or not they need to know how to code. While I don’t believe designers must know how to code, I’ve observed that designers with first-hand knowledge of what code can do — and what it takes to implement things in code — are more effective. Designers who know code communicate more clearly with developers, and have more realistic expectations of what the medium can accommodate. They also have a better understanding of the possibilities the medium affords and can suggest options that wouldn’t have occurred to them otherwise. The result is better outcomes, done faster and with less pain for everyone involved.

Growing Your Area of Concern

Imagine you’re a designer in a team tasked with bringing a product to market. What’s your area of concern?

Perhaps you think of design as your area of concern. You may measure success by the quality of the experiences people have using the product; user testing may validate (or disprove) this. You could also take a wider lens and consider the product as a whole as your area of concern. In this scenario, your role as a designer may take a back seat to your role as a member of this particular product team. You may measure the success of the product (or lack thereof) based on business metrics such as customer engagement, net promoter scores, or sales.

There are wider lenses than these. For example, you may think of yourself as a member of a company of which your product team is but a small part. You may take pride in the company’s overall performance. Or you could go even wider, and think of yourself as a member of an industry. (This lens is especially compelling when dealing with emergent industries that are vying to establish themselves.) Measures with these broader lenses tend to be more abstract; you may celebrate if your company has gained market share, but it’ll be harder for you to tie that increase with your contributions as a designer.

Still, there are even wider lenses. Your company exists within a society. You have a vested interest in having that society become ever better and more resilient. If your society is your area of concern, you may be driven to civic engagement. That said, your role as a designer in a product team also has an impact at this level, even though it may be impossible for you to measure the direct effects of your work at this level. The broadest relevant area of concern — the planetary ecosystem — is so large, and so complex, that your direct contributions may seem very removed from the whole. Here, too, your work has consequences. However, the connection between your role and the ecosystem seems so insubstantial that it’s easy to become blasé.

We must resist this urge to become complacent at the higher levels of abstraction. Growing our area of concern may not seem immediately practical, but it helps create a frame of mind that leads to principled work. Strive to think globally while acting locally — even if the effects of doing so aren’t immediately obvious.


I’m traveling back from Lyon, where I had the opportunity to participate in Interaction 18. It was an inspiring conference, with many presentations devoted to exploring how designers can help make the world better by being more conscious of the systems they participate in and create. I summarized my impressions in a tweet:

The key word here is agency.

Design is central to envisioning future directions; it’s how the possible is made tangible so it can be tested and refined. As such, designers can make real contributions towards shaping the way things work, even if we don’t have direct control over things like project budgets.

Designers don’t need absolute power to make a difference — but we do need a principled approach. Interaction 18 showcased the words and works of designers who are making a difference through their principled approaches. I leave the conference with renewed hope for the future.

What Are You Working On?

One of my favorite questions to ask of designers is “what are you working on?” This is more specific than the more usual “what do you do” — which often leads to dry, rehearsed answers — but broad enough so they don’t feel they need to betray confidences.

Most folks answer with a high-level take on what they do. For example, a person could say she’s working on a healthcare app. Some get a bit more specific; for example, the person could say she’s working on a medical app to help cancer patients monitor their treatment.

The types of answers I get vary depending on whether the designer works independently or as part of a team in an organization. Freelancers and consultants move from project to project, so they tend to have a shorter sense of what “now” means; whereas internal designers are usually part of longer-term efforts.

Another distinction is in the degree to which the person thinks about his or her work as being transformational. The ones who’ve found a way to connect their work with their values are often more enthusiastic, and tend to have a higher-level take on the work. For example, the person could say she’s relieving suffering in cancer patients. (This level of engagement is what I aspire to.)

What about you? What are you working on?

Structure and Change

I’m currently re-visiting Douglas Adams’s wonderful Hitchhiker’s Guide to the Galaxy “trilogy.” In coming back to these books after many years, I was reminded of a quote by Adams that’s dear to my heart:

I love deadlines. I like the whooshing sound they make as they fly by.

Deadlines are important in book publishing. Putting ink on paper is irreversible — and costly. Packaging it is costly. Transporting it for distribution is costly. Shelving it in bookstores is costly. Therefore, making changes after the thing is done is mostly out of the question. There has to be a point in the process where the writer’s work is “done”; a deadline that triggers all these other interdependent parts of the process into motion. It’s a big deal. (Adams was famously late in delivering manuscripts to his editors.)

For most of our history, designers have worked to create artifacts that abide by the laws of physics in the same ways that books do. If you’re designing a wooden chair, someone eventually needs to cut the wood. At that point, you can’t take it back without taking some loss. The same is true for posters, miniskirts, teapots, automobiles, and — especially — the machinery necessary to produce them at scale. As a result, deadlines loom large in the world of design. Designers come to the process with the assumption that there will be a point when their work is “done” — it’s crossed a threshold when things must move on to the next stage in the process.

This is still true for many areas of design, but less so for information architecture. Information environments are never “done” in the same way that a book is done. Information environments are dynamic and interactive. They’re made of malleable stuff: code. Powerful feedback mechanisms are part of their very essence. It does information environments disfavor to think of them as fixed, static things. Deadlines are still important when designing information environments, but they must be put in the right context; they don’t signal the end of the work but a change in focus.

In the introduction to The Ultimate Hitchhiker’s Guide to the Galaxy — the omnibus of all five novels, which is what I’m reading – Adams traces the evolution of the story as it moved from radio to books, to computer games, to the movies, and so on. The Hitchhiker’s Guide kept changing as it migrated to a new medium. Some versions are more definitive than others (the radio play and the novels being the leading contenders), but it’s hard to say any one of them is the “real” story. (Alas, it’s now done; Adams died in 2001.)

Information environments are only ever “done” when they stop being relevant; when the people who manage them stop investing in their continuing evolution. Those of us who design them need always to be thinking about the implications of our work down the line. We may think the object of our work is a taxonomy or some other structural construct, but the thing we’re working on at any given moment is never the final structural form of the environment. It’s only the articulation of a particular snapshot of structural stability in a process of continuous change. The system that shapes these structural relationships is a primary object of interest in information architecture.

Theory and Practice

I sometimes have conversations that go like this:

Me: Have you seen the work x is doing?
Colleague: Yeah, it’s interesting but too academic.

By “too academic,” I think my interlocutor means theoretical as opposed to practical. And I can see he or she means; some work is definitely more theoretical than practical.

This distinction between theory and practice in design is interesting to me. On the one hand, I understand the value of practice. Real-world experiences can generate very useful heuristics. These can then be taught to others, leading to a robust body of knowledge over time.

However, I also see value in a theoretical approach to design work. Where a practical perspective can improve our craft, a theoretical perspective can change how we think of the work itself. This can spark insights that generate new heuristics and breakthroughs.

For example, early in my career, I sensed a relationship between the work I’d learned to do as an architect and the work I was doing designing software. I found no practical manual on how to do this, so I hypothesized connections between the two fields. These connections were not “practical” in the sense that they hadn’t been informed by the craft of designing software. But that doesn’t mean they weren’t useful; they helped give me a perspective that changed the way I approached the work. I tested the theory and developed a set of practical heuristics as a result of this perspective.

This interplay between theory and practice has served as the foundation of my career. I see them as counterparts, not opposites: Theory informs and enriches practice, and practice validates and evolves theory. There’s a place for both in the designer’s toolkit.