The Logic of Conjecture

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


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.


Simplifying My Newsletter

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

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’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

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

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

Adaptive Path 2001-2019

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

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!