Which Watch to Wear to the Apocalypse

Imagine a catastrophic social breakdown, Mad Max-style. An asteroid hits; pervasive coastal flooding causes sudden mass migrations; a genetically modified virus goes rogue; a crazed ideologue with an itchy trigger finger starts World War III. Whatever the case, the systems you’ve relied on for your survival are no longer functioning; you must fend for yourself and your loved ones. As you prepare to head out into the wrecked world in search of food, which watch will you wear?

Humor me with this. There are good reasons to want a timepiece in such a scenario. For example, you may wish to orchestrate maneuvers with fellow marauders as you embark on a raid. Or maybe you’re trying to calculate the speed of a raging river before you jump into it. The fact that all else has gone to hell doesn’t mean time has stopped. Sure, time is an abstraction — but a useful one, even under these dire conditions.

So, which watch will you wear? More specifically, consider these two options: An old Omega Speedmaster and a series four Apple Watch. The Speedmaster — a mechanical watch — only allows you to do a few things: you can tell what time it is, you can precisely measure how long something takes, you can measure how fast something is moving (including yourself, if you’re moving at high speed.) The Apple Watch allows you to do much more. Besides offering the same basic functionality of the Speedmaster, it also allows you to communicate with other people, see what the weather will be like, listen to Beethoven’s 9th Symphony (to remind you why persevering is worthwhile), etc.

In short, the Apple Watch allows you to do many more things that would be very useful in a post-apocalyptic world. The catch, of course, is that many of these features wouldn’t work in this case. When you strap an Apple Watch on your wrist, you’re not just wearing a device; you’re wearing an ecosystem. For example, the usefulness of the weather app depends on myriad things that exist well beyond the object on your person: sensors distributed around the planet, communication networks, data centers, the electrical grid, and so on.

The Speedmaster, on the other hand, depends on none of these things. As long as you remember to wind it every day, it’ll continue performing its functions for a long time. Of course, the day will eventually come when it’ll need repair. At that point, you’re out of luck. (I’m assuming Omega service centers will no longer be open for business.) But mechanical breakdown will likely be years away, even in this scenario. In the apocalypse, the smartwatch’s advantages would vanish within a few hours or days at most, and its essential functions would cease altogether when electricity reserves ran out.

The point of this mental exercise isn’t to get you into prepper mode. Instead, I’d like you to consider the nature of the things you interact with day-to-day — especially if you’re a designer.

We’re used to thinking of things as independent, self-contained objects. A cup is a cup. You can grab it, lift it, turn it around, dip it into liquid, bring that liquid to your mouth. Not much to it! A chair is just a chair. A watch is a watch. Except when it’s digitally enabled. Then it’s something more. Yes, it’s still an object you can pick up and manipulate. But that’s not the point. What’s essential about a smartwatch is that it gives you access to a range of useful features that are only available as long as the systems that enable them are in good working order.

For much of the time that people have been designing things, we’ve created things that are more like cups and chairs — and even Speedmasters — than Apple Watches. As a result, we tend to think of the things we design as individual artifacts with clearly defined boundaries; the kinds of things you can photograph and present in a beautiful coffee table book. Digital things aren’t like that. An app isn’t an individual artifact; it’s a part of (and a host to) very complex systems. Sure, you can show a comprehensive series of screen comps to illustrate what the app will “look and feel” like, but that’s not where its boundaries lie. The screens you interact with when you open the weather app on your smartwatch are a tiny shard of ice on the tip of an enormous iceberg.

Before digital, designers needed some degree of systems thinking. You can’t design something like a Speedmaster from scratch; there are hundreds of years of know-how that precede it, a specialized industrial ecosystem that will produce it, established business models that will get it onto people’s hands, and so on. A designer must understand these things to make the right tradeoffs. Many take these systems for granted as the context within which they’re working, but they must be aware of them nevertheless. Still, I’d venture most folks who design these things don’t think of themselves primarily as intervening in systems.

One possible exception is architects. More than other artifacts, buildings and towns depend on (and enable) rich interactions with their contexts; they depend on complex systems (e.g., transportation, energy, etc.) not just for their design but also to continue serving their functions. As Stewart Brand has pointed out, buildings also change over time as the needs of their occupants and stewards evolve. Smart designers create the means to accommodate change without making too much of a mess. This requires that they understand how the things they design function as systems.

Digital designers must think more like architects than like the designers of cups, chairs, or even mechanical watches. More than any other artifacts we’ve designed in the past, digital things participate in and enable systems. They’re also dynamic and interactive in ways that even complex mechanical devices like a Speedmaster aren’t. Bottom line: You can’t do a good job of designing a digital thing if you don’t understand systems. (This is one of the reasons why I think “product” is the wrong framing for digital things.)

I get tremendous value from my Apple Watch. However, I understand that that value is entirely dependent on complex systems that go well beyond the object on my wrist. When I design a digital thing, I frame it as a systemic design challenge: I look to understand the components and interdependencies that make the thing possible, and how they might change over time. I keep reminding myself that the boundaries for the thing I’m designing don’t lie with the organization that’s commissioned the work or even the operating system within which users will experience it, even if — especially if — stakeholders can’t easily see this. I must think of the thing I’m designing an intervention in one or more systems, and consider the second- and even third-order effects it implies.

And as much as I love my Apple Watch, if all goes to hell, I want a Speedmaster on my wrist.

Against Wireframes

Yesterday I led a bright and engaged group of folks through my Information Architecture Essentials workshop. Most of them were new to the discipline, and wanting to know more. We talked about many things, but had an especially active discussion about wireframes. I don’t like them and haven’t used them in my work for a long time. I thought it worthwhile to document my reasons here, in case it helps anyone.

Wireframes are a design artifact that has long been associated with information architecture. I’ve heard people ask to be “sent the IA” meaning they expect something that looks either like a sitemap and/or a set of wireframes. I consider these “deliverables” to be tools from a prior — more “waterfall” — era of web design and mostly a waste of time today, if not outright misleading. (I include sitemaps in this statement, even though I’m focusing on wireframes here.)

Although I’m sure it’s been written about at length (and better) elsewhere, here are some reasons why I don’t like them:

  • Wireframes are too abstract and not abstract enough. Wireframes are an attempt to explore the relationships between elements in a screen. Often this includes the relative visual priority of things. However, they attempt to extract aesthetics (the “visual design”) from these visual explorations. As a result,
  • Wireframes confuse stakeholders. I think of design artifacts as tools that allow people — both designers and stakeholders — to make design decisions. Wireframes are mostly clear to designers, but not to stakeholders. Asking folks to comment on the relative hierarchy of elements in a visual document while also asking them to ignore the aesthetics of the thing is a tall order.
  • Wireframes are ineffective as decision-making tools. Visual design affects the perception of the relationship of elements on the screen. Font and color choices affect the relative prominence of elements. More abstract wireframes fail to convey these important distinctions. On the flip side, less abstract wireframes are close enough to visual design to derail the conversation towards the lack of aesthetic nuance. As a result, wireframes are seldom effective in helping people make design decisions.
  • “But,” you may protest, “we don’t use wireframes to make decisions. We use them to convey decisions to developers.” Alas, wireframes are also ineffective as design documentation. Wireframes require more effort to produce and maintain than lower fidelity artifacts (like freehand sketches.) Evolution of the design seldom stops when the wireframe deck is complete, leading to either the deck becoming outdated or — worse — design being “fixed” because the wireframe deck is now “signed off.”
  • Wireframes give the impression that things are more polished than they are. I’ve seen designers present early-stage ideas as wireframes. (Perhaps because some folks are uncomfortable drawing freehand?) These artifacts can look very clean and beautiful, leading the viewer to assume that the ideas they present have been thought-through. Often they haven’t.
  • Wireframes are relatively expensive to produce. Given that so many organizations are using design systems these days, building a comp using a tool such as Sketch isn’t that much more work than making a more abstract artifact such as a wireframe.

So what’s a better way of doing it? I prefer freehand drawings, which allow designers to vary the fidelity of artifacts on the fly. Nobody confuses a freehand drawing with a more polished artifact. Freehand drawings are fast, cheap, and disposable; if somebody has a great new idea, you can draw it on the spot. Yes, this requires that designers learn to draw. (I’m still astonished that some people protest this; communicating visually is essential to design work.)

My preferred way of sketching freehand is to use the Concepts app on the iPad Pro. This app treats the lines I draw on the screen as vector-based “ink”; I can select sets of lines and copy them, paste them, delete them, stretch them, mirror them, etc. This allows me to reuse elements (such as window chrome) across drawings, speeding up the process tremendously. Concepts also allows me to share drawings directly to Slack, email, or other channels. The result: very tight feedback loops that enable the design process to move much faster.

What if you’re communicating design intent to developers? In that case, comps or prototypes do a better job than wireframes. It’s not unusual for developers to ask to be sent Sketch files so they can pull out things like colors and element sizes.

Of course, there may be exceptions to all of this. Some teams may have particular circumstances that allow them to move fast using wireframes. Some industries may require them as official documentation. But in my experience, they aren’t very effective. If you’re a stakeholder, don’t waste time and money by asking your designers to create wireframes. And if you’re a designer, learn the basic principles of drawing by hand (such as the use of distinct line weights, how to start and end lines, etc.) You’ll get better results faster.

Design 3.0

My friend Stephen Anderson gave a talk at SXSW 2019 about the future of design. I’ve not seen the presentation itself, but he posted a transcript on Medium. The gist:

Design is in the midst of a shift. A shift that will make much of our present skills obsolete, and demand we learn new skills, or become… irrelevant.

He refers to this as Design 3.0, “a shift from Products to Experiences to Outcomes.” It calls for designers to develop new skills. What sorts of skills? Training machine learning algorithms, monitoring outcomes, modeling possibilities, and reframing the contexts of our work to see the bigger picture. In other words, systems thinking. Design at a higher level of abstraction: designing the thing that designs the thing.

While not a wholly new direction (Gordon Pask was writing about this stuff fifty years ago), technology has finally caught up with the possibilities. So these ideas are very much part of the current zeitgeist. (I’m reading Ann M. Pendleton-Jullian and John Seely Brown’s fabulous Design Unbound, which argues along similar lines. More on that soon.)

Even though the objects of focus for design are changing, the things that make us good designers aren’t. As Stephen rightly points out, designerly approaches such as problem reframing, human-centeredness, and the embracing ambiguity are perennial. They’re also key to doing a good job in this complex new environment.

I’m glad to see design at a higher level of abstraction becoming a thing in the world. I’ve seen few introductions as accessible and compelling as Stephen’s talk; it’s worth your attention.

The Future of Design: Computation & Complexity

Twitter as a Public Square

Managing an information environment like Twitter must be very difficult. The people who run the system have great control — and responsibility — over what the place allows and encourages. In a conversation platform (which is what Twitter is at its core), the primary question is: How do you allow for freedom of expression while also steering people away from harmful speech? This isn’t an easy question to answer. What is “harmful”? For whom? How and where does the environment intervene?

Episode 148 of Sam Harris’s Making Sense podcast features a conversation with Jack Dorsey, Twitter’s CEO, that addresses some of these questions head-on. I was very impressed by how much thought Mr. Dorsey has given to these issues. It’s clear that he understands the systemic nature of the challenge, and the need for systemic responses. He expressed Twitter’s approach with a medical analogy:

Your body has an indicator of health, which is your temperature. And your temperature indicates whether your system more or less is in balance; if it’s above 90.6 then something is wrong… As we develop solutions, we can see what effect they have on it.

So we’ve been thinking about this problem in terms of what we’re calling “conversational health.” And we’re at the phase right now where we’re trying to figure out the right indicators of conversational health. And we have four placeholders:

1. Shared attention: What percentage of the conversation is attentive to the same thing, versus disparate.
2. Shared reality: This is not determining what facts are facts, but what percentage of the conversation are sharing the same facts.
3. Receptivity: Where we measure toxicity and people’s desire to walk away from something .
4. Variety of perspective.

What we want to do is get readings on all of these things, and understand that we’re not going to optimize for one. We want to try to keep everything in balance.

I’d expect the idea to be to incentivize “healthy” conversations over “unhealthy” ones. This would be implemented in the design of the environment itself, rather than at the policy level:

Ultimately our success in solving these problems is not going to be a policy success. We’re not going to solve our issues by changing our policy. We’re going to solve our issues by looking at the product itself, and the incentives that the product ensures. And looking at our role not necessarily as a publisher, as a post of content, but how we’re recommending things, where we’re amplifying, where we’re downranking content.

Twitter has a great responsibility to get this right, because in some ways the system is becoming key public infrastructure. As Mr. Dorsey acknowledged,

Ultimately, I don’t think we can be this neutral, passive platform anymore because of the threats of violence, because of doxxing, because of troll armies intending to silence someone, especially more marginalized members of society. We have to take on an approach of impartiality. Meaning that we need very crisp and clear rules, we need case studies and case law for how we take action on those rules, and any evolutions of that we’re transparent and upfront about. We’re not in a great state right now, but that is our focus. I do believe that a lot of people come to Twitter with the expectation of a public square. And freedom of expression is certainly one of those expectations. But what we’re seeing is people weaponize that to shut others’ right to that down. And that is what we’re trying to protect, ultimately.

As a Twitter user, I was pleased to see the depth of the thinking and care that is going into these issues. I learned a lot from this podcast about the reasons for some of Twitter’s controversial design decisions. (E.g. I now know why Twitter doesn’t have an “edit” button.)

Unfortunately, the conversation didn’t address the elephant in the room: Twitter’s business model. Ultimately, Twitter makes money by showing ads to its users. A good public square shouldn’t attempt to sway our opinions; it should provide the venue for us to form them through engagement with others. How might “conversational health” might be used as a means for persuasion?

Making Sense Podcast #148 – Jack Dorsey

The “Right” Way

Interacting with students is one of the privileges of teaching design at the graduate level. These budding designers are open-minded yet seriously focused on their chosen area of practice, a mindset that offers many opportunities for teaching and learning.

Many of the questions students ask are about the “right” way to do particular things. What’s the right way to diagram a system? What’s the right way to design an interaction? What’s the right way to present this? Is this how a conceptual map is supposed to look? Etc. My reply is often disappointing: There isn’t a “right” way to do it; it depends.

This answer seldom satisfies. But what’s the alternative? There aren’t right/wrong answers in design, only incremental approximations to improved conditions, some of which are preferable to others. Ambiguity comes with the territory, especially at the graduate level. (It certainly does when dealing with clients in “real-world” conditions.)

One of my aims is to help students realize that I’m not there to judge what’s wrong or right; they must develop this sense in themselves. What I can offer is a set of tools and practices that allow them to develop a particular skill: thinking-through-making.

Thinking-through-making is how a diverse group of smart people can come together to solve complex systems problems. These aren’t problems you can solve in your head or by talking with others; you must build models that allow you to externalize your understanding. The act of making the model prompts insights that won’t emerge otherwise. Doing so with others allows the entire group to tap into — and build — their pooled cognitive capacities in an incredibly powerful way.

Thinking-through-making is independent of any particular discipline; it’s evident in architecture, graphic design, interaction design, etc. The feedback loop at the center of the design process is a characteristic shared by all design disciplines. The designer facilitates this feedback loop.

Given the increasingly complex and multi-disciplinary challenges we face, it behooves us to think about design independently of our particular areas of practice. We can leverage our individual expertise in service to bringing diversity to the team; of proposing alternative approaches that may otherwise been missed. But at the core is design, a way of solving problems that doesn’t offer on-the-spot “right” answers but evolves incrementally towards better.

The Client-Designer Relationship

Designers gather input from various sources that affect the direction of a project: There’s bespoke research around the problem space, relevant case studies, regulators (both external and internal), subject matter experts, validation sessions with end users, etc. But there’s one entity that tends to have more influence on the direction of the project than others: the client.

By “client” I mean the entity that has commissioned the design project — i.e., the person or team who is paying the designer to focus his or her attention on the problem at hand. The client has money and reputation at stake; the designer has a contractual obligation to deliver results. The client is tasked with changing the state of whatever is being designed. “We are at point A, and need to get to point Z by X date.” The designer is there to shepherd that transformation through designerly means; that is, by manifesting key decisions in ways that reflect intended changes so they can be tested against reality.

The designer has an important responsibility in creating these feedback loops, but the client ultimately owns the results. This is obvious when the designer is engaged as a consultant – i.e., not an employee of the client’s organization — but is no less true when the designer is an “innie.” Many internal design teams don’t “own” the things they’re designing; they work with counterparts in other parts of the organization who have bottom-line responsibility for the thing being designed.

Charles Eames's sketch of the design process. Image: Eames Office. http://www.eamesoffice.com/the-work/charles-eames-design-process-diagram/
Charles Eames’s sketch of the design process. Image: Eames Office.

The client-designer relationship is central to the design process. Understanding the dynamic of this relationship, and knowing what each party is expected to bring to the process, is key to success. That said, it is up to the designer to ensure that directions are clear. In architectural projects, these directions are often manifest in the form of a brief, or architectural program: a document that lays out the requirements for the project.

The content for this brief must ultimately come from the client, but is formulated in close collaboration with — and often led by — the architect. Architects shepherd what is an initially vague set of requirements towards something more specific and actionable, much like they shepherd design artifacts. The brief is a sort of meta-design artifact that is also designed. Given its importance to the project, the designer and the client must develop it together.

Successful design projects call for relationship-building among all parties involved. Few relationships are as important to the success of the project as that between the client and the designer. At best, these relationships are true partnerships, with both parties having a healthy respect for what the other brings to the project. That said, both parties can’t be expected to have the same degree of understanding of this fact. While this may be the one time in his or her career that the client will be working with a designer, the designer will work with many clients over time. Because of this, it behooves designers to understand the client-designer dynamic and create the conditions necessary for these relationships to be fruitful.

A Data Primer for Designers

My friend Tim Sheiner, writing for the Salesforce UX blog:

demand is high for designers who can create experiences that display data in useful and interesting ways. In my personal experience this became much, much easier to do once I’d learned to speak the crisp, precise and slightly odd language used by technical people for talking about data.

What follows is a phenomenal post that clearly explains much of what you need to know to understand and speak competently about data. A must-read for anybody involved in designing for digital information environments.

Designer’s Field Guide to Data

Towards Greater Diversity in Design Teams

The websites and apps you interact with are parts of systems. These systems are often commercial organizations with responsibilities to various stakeholders, including the owners of the business, its employees and managers, its customers, and — more broadly — the rest of us who live in the society where the organization operates.

The people who “own” these digital products and services — product owners, business line managers, etc. — are tasked with being good stewards of these systems. They’re called to steer them towards greater value for stakeholders in the short and long term even as conditions around the systems change. Design decisions will change these systems — even if slightly. For example, the team could develop a new feature, fix an existing (and underperforming) feature, or address an entirely new user audience.

These are systemic interventions. Their effects are seldom limited to the task at hand; a seemingly minor alteration could have a large impact downstream. As a result, product owners must look out for second- and third-order effects; they’re looking to intervene skillfully as the system faces perturbations in its context.

To do this, product owners must become aware of the possible options open to them and their potential effects. Their ultimate goal is to achieve dynamic stability: for the system to continue serving its intended purposes as it evolves over time to address changing conditions. This calls for these folks to become systems thinkers.

One of the central tenets of cybernetics — the science of systems — is the Law of Requisite Variety. It’s relevant to people who aim to control systems. In cybernetics, the word variety has a special meaning: It refers to the number of possible states of a system. The Law of Requisite Variety suggests that skillful control of a system requires (at least) an equal number of possible responses to its number of possible states. This is usually articulated as a maxim: only variety can destroy variety.

Translation into humanspeak: a system with few possible states requires a small range of responses, whereas a system with many possible states requires a broad range of responses. This idea has proven to be useful in a variety of fields, including sports, ecology, management, medicine, and more. The more complex the system you’re dealing with, the more states it can be in. Controlling such systems requires at least an equal amount of flexibility in your ability to respond to changes.

Of course, not all digital products and services aim to serve the same purposes. Some are simpler — and less ambitious — than others. Simpler systems will have — and require — less variety. But many digital products and services are very complex and can have many possible states. A digital system that aspires to become the de facto environment where we interact — socially, commercially, civically, etc. — will have a huge range of possible states. The folks who design and manage these systems face a great deal of variety. To intervene skillfully, they need a larger range of possible responses. Among other things, this calls for greater diversity in their teams.

Purposeful Governance

Some systems are best left alone. For example, a rainforest can function perfectly well without human intervention. That’s a natural system that evolved into its current configuration over a long time, and it’s likely to continue adapting to changing conditions. (Barring some major environmental disruption.)

Most human-made systems haven’t had as much time to adapt; they’re aggregates of design decisions that may or may not effectively serve their intended purposes. Some of these interventions may truly be in service to the systems’ goals, but others may be driven by political motivations. (That’s one reason why you should think small when designing a system from scratch.)

As with the rainforest, conditions around the man-made system will change over time. How will the system address these changes? Designing the system itself is not enough; the design team must also design the system that continues the ongoing design of the system. We call this governance. Governance, government, governing; they all have to do with ongoing interventions aimed at keeping systems functioning as intended. These terms are all derivates from the Greek word kubernan (“to steer”), which is also the root for the word cybernetics. Governing is a quintessential systemic activity.

When do you intervene? How do you intervene? With how much force? How frequently? Who intervenes? If the intent is to keep systems functioning for a long time, these questions are essential. They also imply a corollary: you must know what you’re governing towards. What’s the purpose of the system? What are its intended outcomes? You can’t steer effectively if you’re unclear on the destination.