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

TAOI: IDAGIO

| Jorge Arango

The architecture of information:

IDAGIO is a music streaming service. It competes with the likes of Spotify and Apple Music — big players with deep pockets! But IDAGIO is different: it only streams classical music.

If you’re into classical music, you know the other music streaming services aren’t good at classical. Not because of the quality of the recordings, but because they’re set up for pop music, which is usually consumed in single tracks. Classical music, on the other hand, is usually presented in “works,” compositions that consist of several tracks. Structuring information in this way is the first feature IDAGIO highlights on its homepage:

The best search
Unlike other streaming services, we organise music by work not track. Compare all recordings of your favourite work, browse different interpretations, and find the latest albums.

Information architecture as strategic differentiator.

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

Proudshamed

| Jorge Arango

Paul Ford, writing for WIRED:

NERDS, WE DID it. We have graduated, along with oil, real estate, insurance, and finance, to the big T. Trillions of dollars. Trillions! Get to that number any way you like: Sum up the market cap of the major tech companies, or just take Apple’s valuation on a good day. Measure the number of dollars pumped into the economy by digital productivity, whatever that is. Imagine the possible future earnings of Amazon.

THE THINGS WE loved — the Commodore Amigas and AOL chat rooms, the Pac-Man machines and Tamagotchis, the Lisp machines and RFCs, the Ace paperback copies of Neuromancer in the pockets of our dusty jeans—these very specific things have come together into a postindustrial Voltron that keeps eating the world. We accelerated progress itself, at least the capitalist and dystopian parts. Sometimes I’m proud, although just as often I’m ashamed. I am proudshamed.

This piece captures a mood I’ve perceived among my cohort of techie designers: A radical swing from the unbridled optimism many of us felt in the 1990s — the sense that the internet was a transformational force comparable only to Gutenberg — to moroseness and guilt at the effects of these changes on society.

The transition from the Middle Ages to the modern era was anything but smooth. Gutenberg’s innovation wrought tremendous upheaval: Long-standing mental models collapsed; social and political systems were replaced. The technological changes of the last five decades — the wiring up of the planet into a real-time nervous system that democratizes access to the world’s information — are in some ways more radical than those of the 15th-16th Centuries. We’ve not just changed the ways we interact with each other and the world, we’ve changed change itself — scaling and speeding it up in ways that lead to unpredictable outcomes.

The article frames (digital) technology as an industry alongside others such as energy and finance. That’s a common underestimation spurred by the pervasive mental model of our time: that of the market economy. Yes, tech is an industry in that sense. But tech is also a meta-industry: it changes the character of the other industries thoroughly. The call to more responsible design is urgent not because tech requires it, but because we are re-building society atop tech.

Why should we expect such radical changes to be easy or comfortable? People of my vintage (I’m squarely Gen X) and younger in the developed world have thus far led lives of relative peace and stability. Cold War notwithstanding, we came of age inside a certainty bubble. When dealing with (deep) disruption, we fail to account both for the fragility of social institutions and the resilience of individuals under such conditions.

Mr. Ford concludes:

I was exceptionally lucky to be born into this moment. I got to see what happened, to live as a child of acceleration. The mysteries of software caught my eye when I was a boy, and I still see it with the same wonder, even though I’m now an adult. Proudshamed, yes, but I still love it, the mess of it, the code and toolkits, down to the pixels and the processors, and up to the buses and bridges. I love the whole made world. But I can’t deny that the miracle is over, and that there is an unbelievable amount of work left for us to do.

I, too, feel lucky. Yes, there is lots of work to do. But the miracle is far from over; it’s ongoing. Responding skillfully to the changes it bring requires being present; that we see clearly so we can use our (real!) abilities towards increasing agency and compassion.

WHY I (STILL) LOVE TECH: IN DEFENSE OF A DIFFICULT INDUSTRY

Simplifying My Newsletter

| Jorge Arango

I’m not sure if you’re aware of this, but every two weeks I send out a newsletter. It started shortly before Living in Information was published, in response to folks who’d asked to be notified about the book’s progress.

Over the past year, the newsletter has grown — both in reach and size. Having coffee with a close friend this week, he confided that he doesn’t read the newsletter any more because messages have gotten too long. (See for yourself.) I’ve also gotten feedback through other channels that, while useful, my messages have become unwieldy.

It’s time to do something about it. I’ve redesigned the newsletter’s format to focus on the essential: helping folks design information environments more responsibly, with a couple of cool things thrown in to spice things up. I’ll also occasionally add notices about upcoming workshops and such. But the main drive will be sharing useful information in an easy-to-digest format.

The first issue featuring the new design goes out early tomorrow morning. Sign up here to get it. And if you’re already receiving the newsletter, I’d love feedback — please let me know what you think of the new design.

Establishing Context Through Navigation

| Jorge Arango

The most important purpose of navigation structures in a website or an app is allowing users to move around. Links on​ a navigation menu make it possible for a person to go to different parts of the information environment​; they give the user clues on where they can go next. However, these structures also play another important — and often unacknowledged — role: they help establish the right context in the user’s mind. By this, I mean that they help answer the following questions:

  • Where am I?
  • What type of place is this?
  • What can I do here?

These questions are on people’s minds when they come to a new information environment — and navigation can help answer them. The distinctions we establish through the choices in a navigation menu tell us something about the place. Take a look at the following options from a navigation structure; let’s call it structure A:

  • Studio
  • Classes
  • Poses
  • Schedule
  • Search

You may not know what these options refer to, but a picture may be forming in your mind — a picture triggered by this unusual collection of words. Compare that with another structure, let’s call it structure B:

  • Products
  • Services
  • Support
  • About us
  • Search

Whereas structure A may pique your curiosity, I bet you don’t find structure B surprising: you’ve likely encountered it in many other information environments. “Products” and “Services” are generic terms; they could refer to anything. Structure B could work for healthcare or financial services or a myriad other fields. Structure A, on the other hand, is much more specific: that particular collection of words is likely to occur only in a few areas.

A new user encountering structure​ A must imagine him or herself in a particular context for these choices to make sense. This takes some cognitive effort. The labels in structure B, on the other hand, are familiar — clichéd, even. This can be useful: The user doesn’t need to know how the place is different in order to predict what s/he’ll find in each area of the environment.

On the flip side, the more generic labels in structure B sacrifice something important: the opportunity to quickly put the person in the right mindset to make skillful use of the place. Structure B trades off specificity for familiarity; “services” hints at a much broader range of possibilities than “classes.” This tradeoff influences people’s ability to understand the place. It also affects the positioning of the environment in search engines, since there are many more information environments offering “services” than “poses.”

One of the potential downsides of using domain-specific labels is that the more specific labels can be obscure, so you risk alienating visitors who don’t yet understand the subject matter domain. I see this most often with navigation structures that use proprietary labels (e.g., brand names.) If the proprietary name is relatively new, users may not know what it refers to. So these structures work best when the proprietary names are well known. For example, consider the following options:

  • Office
  • Windows
  • Surface
  • Xbox
  • Deals
  • Support

You may have already guessed that this is from Microsoft.com’s primary navigation bar. Here the (otherwise) generic words “office,” “windows,” and “surface” refer not to the everyday concepts bearing those names, but to well-known brands. This set of labels depends almost entirely on their context — which they reinforce. If this site wasn’t related to Microsoft somehow, we’d be wondering why we’re seeing this particular collection of concepts.

The set of labels we present in navigation structures help people move around. But they also frame the experience. They put the user of the environment in a particular mindset. For example, imagine you stumble unto a website that offers the following options:

  • Banking and Cards
  • Loans and Credit
  • Investment and Retirement
  • Wealth Management
  • Rewards and Benefits

I don’t need to show you anything else — not even the website’s name — for you to know that you’re now in some kind of financial services environment. Just looking at the words would lead you to conclude this is most likely a bank. And if you’ve had experience with online banks in the past — a safe bet for many users — you’ll have expectations about what you can find and do in each of the areas of the environment. For example, you’d expect such a place to have a way for you to log in to see your own accounts and to transact with the organization, since that’s a feature offered by most bank’s websites. If your structure doesn’t allow users to do this, they’ll be wondering why.

When establishing a new navigation structure — especially its top-level options — you should strive to have the set of choices create and reinforce the right context. Ask yourself: Are the options understandable? Are they particular to this information environment? Do they help the environment stand out? Or are they generic? Are we establishing the right degree of familiarity for this environment? Are we sacrificing understandability for expedience? Getting the balance right requires a clear understanding of the people will be using their environment — especially the degree to which they already understand the subject matter and the organization’s role — and lots of testing.

“Build More Roads” is Often the Wrong Answer

| Jorge Arango

The Power Broker, Robert Caro’s masterful biography of Robert Moses, tells the story of how modern New York City came to be. Moses and his team were responsible for some of the most important public infrastructure interventions in and around New York City during a span of four decades starting in the mid-1920s. Under Moses’s leadership, the city gained new parks, playgrounds, bridges, and especially roads — sometimes at the expense of beloved neighborhoods and the disruption of countless lives. An unelected official, Moses became incredibly powerful; you can see his influence in New York even today.

The core of Moses’s power lay in the Triborough Bridge Commission, which controlled the flow of traffic between Manhattan, The Bronx, and Queens. Tolls from vehicles driving across the Commission’s bridges generated immense revenues that paid for other projects, which in turn generated more revenues. For Moses, vehicular flow in New York City’s streets translated directly to more power. Thus, when considering means for transporting the city’s inhabitants, Moses’s team would gravitate towards more roads — even when it’d become clear that building more roads only increased congestion. The result was the defacement of major parts of the city with highways and roads that were constantly jammed with traffic.

You gotta watch incentives.

This comes to mind because of something that Jessica Ivins said on her interview for The Informed Life podcast:

So not everybody has the detail-oriented mind that I do, or not everybody works the same way I do. And because we’re small and I’ve been working here for almost 5 years, I have a sense of what works well for my co-workers. So for example, my coworker Thomas, I will assign him a to-do in Basecamp and he’ll get an email notification, but I’ll also send him a notice on Slack. And I’ll say, “Hey Thomas, I signed you this to-do on Basecamp, please review it by this date and see the to-do for details.” And that Slack message really helps him because he… I guess some people are really good at wrangling their inbox, other people really struggle with it. And I think that’s really typical.

It is typical. I’ve faced similar situations in other projects: Someone new joins the team, and you don’t yet know their communications preferences. Are they an email person? Do they prefer Slack? Or maybe iMessage? It’s not unusual to get a message in Slack followed by an email asking, “Did you see the message I put in Slack?” And of course, people’s preferences vary depending on other factors. For example, perhaps they only use Slack on their computers and find it easier to respond via SMS when they’re on the road.

Proprietary communications systems like Slack and Basecamp set out to solve the problems with older systems like email (and there are many!), but like Moses’s roads they can end up creating other problems. Now instead of one or two places to check your communications, you have five. You get reminders on one system (e.g., email) to check messages sent to you on another (e.g., Basecamp.) I’ve gotten messages on Slack to check something that was posted in Basecamp; later that evening I’ll also get an email reminder from Basecamp of all the things that were posted there during the day. The signal-to-noise ratio goes through the floor. And of course, now you have to keep track of where you saw the message or file if you ever need to get back to it. (“Did you send that document over email, or was it in Slack?”) As far as I know, it isn’t possible to search across all of these systems; it’s up to you to keep track of where things are. This is difficult, given the challenge I mentioned above. (I.e., different people have different communications preferences.)

The added complexity would be worthwhile if these systems enabled amazing new ways of working, but these proprietary communications systems bring little new to the table; most of the functionality they enable has been around for a while. Check out Jon Udell’s book Practical Internet Groupware for the state of the art twenty years ago; you’ll find lots that is familiar. It’s worth noting that that book advocated for building these communications systems atop existing open standard technologies. In this sense at least, the current state represents a regression from where things were in the late 90s.

I’m cranky about this stuff because in the past month I’ve joined three new Slacks and one Basecamp project. This is part of the job when you’re an independent consultant who works on several projects with different teams throughout the year. But I don’t enter these spaces casually. As someone who thinks about the longevity and resilience of information ecosystems, I’m concerned about my ability to find and keep track of stuff — especially in the long term. I dislike the proliferation of disconnected, single-purpose silos of information. While the discussions that happen in these places can be rich, vibrant, and productive (that is, when they’re not generating more noise in other channels), they’re locked away, inaccessible for future (even near-future) reference.

In the long term, building more roads isn’t the solution to the challenge of moving lots of people from one point to another. Past a certain volume, individual vehicles are inherently inefficient; one needs to re-think the structure of the transportation system from the ground up. This is more challenging if the people charged with the stewardship of these systems are incentivized to get more cars on the road. I sense similar problems with the communications challenges we face in organizations. When what you’re selling is access to Slack, your incentive​ is to get more people using Slack. That’s a different goal than getting people to communicate effectively. Yes, there is some overlap there — up to a point. How does the system scale?​

The Informed Life With Jessica Ivins

| Jorge Arango

Episode 9 of The Informed Life podcast features an interview with UX designer and educator Jessica Ivins. Jessica teaches at Center Centre, the UX design school in Chattanooga, Tennessee. This is a role that requires that she wear many hats:

I do everything from emptying the dishwasher, to writing curriculum, to reporting anything; any issue with the facilities that needs to be repaired… Lots and lots of work with the students, obviously: working with them one-on-one working with them in the group setting. So it’s really a lot of juggling and a lot of time management and priority management.

Her goal is one many of us can relate to: “to juggle all the things I need to juggle and do all the things I need to do without burning out and without working long hours.” And in 2018, she did it! How? Through a combination of tools and practices, including Basecamp, Google Docs, timeboxing, and by following David Allen’s Getting Things Done methodology.

This episode inaugurates a new look for the podcast’s website. Abiding by the “shitty first draft” principle, I launched the show in January using a very basic WordPress theme. As some astute listeners pointed out, this first theme had awkward issues, especially on mobile. Hopefully the new theme fixes that. Please let me know what you think.

The Informed Life Episode 9: Jessica Ivins