Design

Book Notes: “Design Unbound”

| Jorge Arango

Design Unbound: Designing for Emergence in a White Water World
By Ann M. Pendleton-Jullian and John Seely Brown
The MIT Press, 2018

Most people think design is about making better things: a more engaging website, a more usable gadget, a more satisfying experience, a bigger logo, etc. More enlightened folks will quote Steve Jobs, saying that design isn’t how something looks but how it works. While that sentiment is indeed a deeper take on design, it still misses an important point: design is not just about making things, it’s also a way of knowing and intervening in the world. And it’s a special way, since it allows us to tackle what Horst Rittel and Melvin Webber dubbed wicked problems.

Most designers (or the general public, for that matter) don’t see design in this light. This book aims to change that. The preface to the first volume spells out the works’ goal:

Design Unbound set out to define a new tool set for the world we find ourselves in — a world that is rapidly changing, increasingly interconnected, and where, because of this increasing interconnectivity, everything is more contingent on everything else happening around it — much more so than ever before.

The authors use the analogy of white water kayaking to describe complex decision-making under such dynamic conditions. Navigating a turbulent river calls for a completely different approach than doing so in a calm lake. “The interesting thing about white water rivers is that they are navigable,” they state, “but under new terms.”

Design Unbound offers a set of design practices and mental models – “an offspring of complexity science, married to architectural design” — to help us navigate complex challenges. These “tools” include a reframing of design briefs, critique, ambiguity, skills, emergence, world-building, networks, and “intervals of possibility.” The book also features several meta-tools, which reframe design practice itself for work at a higher level of abstraction.

These concepts are presented in five books over two volumes. The authors suggest that the work doesn’t need to be read linearly, and offer a useful (and beautiful) guide to its content:

A map to the content in Design Unbound

This is a map for pragmatic design-doing — not for making widgets better (or even better widgets), but operating at a much higher, systemic level: that of social, economic, ecologic transformation. Design enables us to engage these domains through abductive reasoning, a different way of knowing (and acting in) the world than the better-known modalities of deductive and inductive reasoning. I first encountered this powerful idea in Nigel Cross’s Designerly Ways of Knowing, where it’s presented in the abstract. Design Unbound offers concrete practices that allow us to put it in action.

The two volumes of this work comprise a rich and valuable framework for tackling some of our most pressing and complex challenges. I’ll be returning to its pages often, both in my practice and teaching.

Buy it on Amazon:

Design Unbound, Vol. 1

Design Unbound, Vol. 2

The Logic of Conjecture

| Jorge Arango

I once worked with a stakeholder who was into numbers. We were redesigning the company’s primary navigation system. We’d planned some quantitative tests on the new structures, but they weren’t enough. Our stakeholder wanted decisions based on hard data. I sensed that this was a call for certainty; a way to dispel criticism of the work, to provide cover in a tough political environment.

Certainty is a tricky aspiration. Design is, by definition, uncertain: You’re trying to give tangible form to a possible future so that you can test it. You go into this knowing that early iterations will be wrong. (Hopefully, they’ll be usefully wrong.) The whole point is to start a feedback loop that leads to something good.

How do you know it’s good? Because it’s evolved through interactions with the real world. You’ve put it (or something that looks and feels and works like it) in front of real people, you’ve seen them use it, you’ve changed it based on their reactions. At some point in the process, you start to develop confidence in the direction. (Only confidence; never certainty.) The early stages are fuzzy. Yes, data can help — mostly, to give you a read on the current context. But data can’t dictate design directions. That requires design intelligence, experience, and craft. (Perhaps the day will come when algorithms can do part of this work, but they’re not here today.) This is what designers call abductive reasoning.

In his book Designerly Ways of Knowing, Nigel Cross introduces the concept by contrasting it with inductive and deductive reasoning:

[Philosopher Charles Sanders Peirce] suggested that ‘Deduction proves that something must be; induction shows that something actually is operative; abduction merely suggests that something may be.’ It is therefore the logic of conjecture…

Design ability is therefore founded on the resolution of ill-defined problems by adopting a solution-focussing strategy and productive or appositional styles of thinking.

I love this image of design as a solution-focussing strategy. It suggests that while the goal is clarity, getting there requires dealing with fuzziness. Ideally, the process moves from an ambiguous state to one that is sharp and detailed. In the course of the project, you get a better sense of what the solution is.

Ann Pendleton-Jullian and John Seely Brown’s Design Unbound describes abductive reasoning thus:

[it] is often understood as a “best guess” hypothetical reasoning — a form of logical inference in which an observation leads to a hypothesis which might explain the observation. The hypothesis can then be tested. In abduction, one is seeking the simplest and most likely explanation, without enough facts for a foothold on certainty.

Designers need to acknowledge that working like this can be scary, especially in projects undertaken under challenging conditions and/or where there’s a lot at stake. It’s scary because there’s a lot of uncertainty in the process, especially early on, and people whose jobs are on the line will want to reduce uncertainty as much as possible. It’s also scary because this requires trusting the people shepherding the process; there’s no cover in numbers. The upside: abductive reasoning can help teams deal skillfully with complex, ill-defined problems. It can lead to a good solution faster than any other approach I know. (Note I didn’t say it’ll lead to the perfect solution — for complex problems, there’s no such thing.)

Adaptive Path 2001-2019

| Jorge Arango

For a particular generation of designers, the name Adaptive Path holds special meaning. No matter where in the world you were practicing, if you were doing what we now call “user experience” design, you were likely to be paying attention to this most prominent of UX consultancies. Its founders included luminaries of the field, many of whom were (are) vocal in sharing what they learned both through blogs and in the conference circuit. Over the years, AP contributed much to our understanding of what it means to practice good UX design.

I’m using the past tense because now that name is no more. In a short Medium post published yesterday, the AP brand bade us farewell; it is henceforth to be fully integrated into Capital One, the financial services company that acquired Adaptive Path in 2014.

AP stopped taking on external clients at that time. For those of us who were consulting elsewhere, this meant they were effectively out of the playing field. With one exception: even after the acquisition, Adaptive Path kept putting on some of the best yearly design conferences in the world. I was fortunate to speak and/or lead workshops at the most prominent of these: UX Week.

I was confused by the way the Medium post described the future of AP’s events:

it’s bittersweet to say goodbye to our beloved Adaptive Path brand, and to all our events like UX Week, LX: Leading Experience, The Service Experience Conference, and design intensives.

Does this mean these events won’t happen anymore? Or merely that they won’t happen under those brands? In the ensuing discussion on Twitter, we got confirmation that the events are done, at least in the form we knew them:

As cliched as this sounds, this marks the end of an era. A small design consultancy has a very different character than a large financial services company; the types of events and “thought leadership” that come out of either will be (by necessity) very different. Even in its post-acquisition state, AP continued serving an important role in the UX design community through its events. Their withdrawal from the market leaves a large vacuum.

Thanks for everything, Adaptive Path. I learned a lot from you all over the years. It was a privilege to be associated with you, even if only in minor and tangential ways. To my former AP friends at Capital One: I wish you the best and look forward to seeing what you come up with next.

Design as an Antidote to VUCA

| Jorge Arango

A short presentation I shared as a videoconference with Rosenfeld Media’s Enterprise Experience Community.

In the early 1990s, the U.S. Army War College created an acronym to describe the geopolitical situation following the Cold War: VUCA. It stands for volatility, uncertainty, complexity, and ambiguity, four characteristics they saw as defining the multilateral post-Cold War world. The rise of information technologies — and the internet in particular — has radically transformed our political, economic, and social reality. We are all now living in a generalized state of VUCA. We see signs of it everywhere — including the enterprise.

Design can be a powerful organ for organizations dealing with VUCA. In this presentation, I give some reasons why. I also cover some reading materials that have led me to this line of thinking. I was gratified to see participants in the videoconference suggest other resources worth investigating if you’d like to delve into design’s more strategic value; I’ve added those recommendations into my reading list.

Books I referenced in my presentation:

I also called out these recent Medium posts:

Other folks in the call suggested the following additional resources. (I’ve listed them here in the order in which they were suggested.)

I have a lot of reading to do! I was familiar with some of these resources, but not all of them. That’s one of the upsides of sharing incipient ideas with a smart group of folks like the Enterprise Experience community: you get to hear from other folks who know more about other parts of the domain. I’ll be digging into these books, posts, and videos for sure!

A Brush With Resilience

| Jorge Arango

The iPhone in my pocket is a miracle: an encyclopedia, a communicator, a calculator, a notebook, a library, a compass, a tape measure, a camera, a flashlight, a watch, etc. Yet for all of its capabilities, it’s also not very durable. In another year, my iPhone will start to feel sluggish, and its battery won’t last a full day. In another ten years, it’ll practically be useless. This is partly by design and partly because its technologies evolve so rapidly.

Not all things are designed to be ephemeral like the iPhone. Yesterday my family and I visited the SS Red Oak Victory, a World War II ship that is part of the Rosie the Riveter WWII Home Front national park in Richmond, CA. The Red Oak was built in 1944 and is a marvel of 1940s-era engineering. What amazed me most is how many of the ship’s communication technologies are still operational.

For example, the ship’s internal telephone system, which is powered by small hand-cranked electrical generators, still works, as does its late-1940s radio. When compared to my iPhone, these things are incredibly crude, of course. But the fact that they’re still in good working order after 70 years was illuminating.

This is by design. The conditions under which the Red Oak operated demanded resilience. Its operators could find themselves in remote ports of call, with little or no access to expertise. They would need to fend for themselves, and the ship was designed to make this possible, if not easy. It was built to be easily repaired and maintained by the people who operated it; people who wouldn’t necessarily have advanced engineering knowledge.

Also, the Red Oak wasn’t mean to be consumed. That is, it’s not an artifact designed to generate ongoing want, to be discarded and replaced. There are redundancies — inefficiencies — everywhere. The ship’s components are large and sturdy. They weren’t designed for portability, efficiency, or economy — they were built to last.

I don’t expect the same degree of resiliency in my iPhone. But touring the Red Oak made me think about how we can make the things we experience on the iPhone — our information environments — more like that ship; better able to stand the test of time.

Systemic Design Beyond the Screen

| Jorge Arango

Last evening I introduced students in my systems studio class to their final project for the semester. The project has them designing an intervention to help individuals with their financial health. I must call it an “intervention” because I’ve been trying to steer the students away from thinking about the things they’re making as manifesting exclusively through screens.

It’s a challenge. Designing at a systemic level calls for thinking abstractly, and looking at the entire ecosystem one is designing for. However, systemic change happens as a result of concrete interventions: Something must serve as the catalyst for change, and that something must be made tangible somehow. Given how much time we spend interacting with and through screens, it’s natural to immediately gravitate towards solutions that involve software experienced through (especially) mobile app screens.

While software can be incredibly powerful, to think exclusively about the objects of interaction design as screen-based experiences is to limit ourselves unnecessarily. Our bodies and the world they inhabit are incredibly rich; screen-based experiences collapse that richness into relatively small windows that concentrate everything into what you can experience through a small glass rectangle.

We have so many more possibilities to choose from! What if the object of design were a new ritual? Or how about language? (“Create a new way of talking about the domain that opens up new possibilities.”) And of course, service design offers a broad range of possible interventions well beyond what can happen through screens.

Of course, I’m not opposed to screen-based interventions. The problem is that we’re so used to them that students run the risk of 1) immediately gravitating towards cliched solutions, and/or 2) not thinking about the problem as a systemic design challenge, thinking instead that they’re working on an “app” (something they’re more familiar — and therefore, more comfortable with.) I’m hoping that nudging them to think beyond the screens can help them think more systemically and propose more interesting (and fresh) solutions.

Which Watch to Wear to the Apocalypse

| Jorge Arango

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

| Jorge Arango

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

| Jorge Arango

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