Meeting the User

Early in my career, a support incident taught me a lesson about mental models. Here’s what happened: I was contracted to create a small promotional app for executive assistants who used Windows PCs. Many didn’t have CD drives, so the app was designed to fit on a floppy disk.

To install the app, users would slide the disk into their computer and double-click on a file called something like INSTALL.EXE. Then they’d follow the onscreen prompts. The disk included printed instructions that spelled out the process.

Shortly after we released the app, I got a message from the client. A user was having trouble installing the app. Would I mind taking a look? So I drove to the user’s office and asked her to show me what she was doing. What I saw blew me away.

Continue reading

Shipping the Org Chart

While reorganizing my library a few weeks ago, I came across a handout from a 2003 workshop by my friend Lou Rosenfeld titled Enterprise Information Architecture: Because Users Don’t Care About Your Org Chart.

Lots of ideas quickly become obsolete in tech. But after 18 years, the idea that users don’t care about your org chart is still relevant. Teams still ship systems that reflect their internal structures. IA is still crucial to addressing the issue.

Few teams set out to design inwardly-focused systems. Instead, they inadvertently arrive at solutions that feel “natural” — i.e., that mirror their structures. Subtly, the systems they design come to reflect distinctions inherent in their orgs.

Continue reading

Design as an Effective Agent of Change

As software continues to eat the world, digital systems’ conceptual structures matter more than ever. It’s easy to nudge users towards particular choices by making them more prominent. We can use this power for good or bad.

For example, are we helping people eat healthier? Or addicting them to unnecessary services? Alas, choices aren’t always as clear. And even in “clear” cases, we may not be the best arbiters of “good.” Often, the lines between good and bad are blurry.

For example, some retailers tweak search results towards commercial goals. Is that wrong? It depends. Are customers still seeing relevant results? Will they benefit? Same with navigation: It’s easy to bury “undesirable” choices deep in menus.

Continue reading

How to Work with Tension in Design

The ultimate purpose of a design project is to change something. It might be kickstarting sales, making stuff more findable, or addressing a competitive challenge. Whatever it is, the project exists because someone wants something to be different.

Changes reveal tensions. Often, teams are invested in the status quo. For example, sales may want product to introduce new features, while product wants a simpler experience. More capabilities increase complexity, so the two are in tension.

Projects are rife with such tensions — and they often go unacknowledged. Not surprising, since dealing with tensions can be uncomfortable. If you’ve ever been in a meeting with a surly stakeholder, you know how awkward these situations can be.

Continue reading

Clarity vs. Confidence: Starting Conceptual Models Right

Few things are as powerful as a good model of a complex domain. A clear representation of the domain’s key elements and their relationships creates alignment. The model becomes a shared point of reference and shorthand for decision-making.

Good models eschew some complexity. But complex domains aren’t simple. A model that aims to encompass a domain’s full complexity will likely fail at building shared understanding. But a model that over-simplifies won’t be useful.

Continue reading

The Key to Understanding Why Things Happen

When a systems thinker encounters a problem, the first thing he or she does is look for data, time graphs, the history of the system. That’s because long term behavior provides clues to the underlying system structure. And structure is the key to understanding not just what is happening, but why.

— Donella H. Meadows, Thinking in Systems

Every year, I introduce systems students to the iceberg model. The model is a helpful way of understanding situations by looking ‘beneath the surface’ of the things we experience, to the structures and mental models they manifest.

In case you’re unfamiliar with the iceberg model, it’s a framework that encourages you to think about situations at four levels:

  1. Events, or the tangible manifestations of the situation; the things we can see, hear, and record — “just the facts.”
  2. Patterns we perceive in events; outcomes that happen not just once but manifest time and again.
  3. Structures that may be causing the patterns we perceive; these could include rules, regulations, incentives, etc.
  4. Mental models that bring these structures into being.

Notice the fourth level is more abstract than the first: we can ascertain events, but we must hypothesize mental models. There’s also a causal relationship between levels: mental models elicit structures that elicit patterns of events.

As a result, events are easier to grok than mental models. But as with pace layers, the deep levels are where the true power lies. A change at the level you can see has less impact than tweaking the mental models that bring it forth. The ability to change minds is an incredibly powerful lever.

The iceberg model is helpful when doing research. Research produces lots of data points: Google Analytics and search logs tell you about usage, landscape analyses tell you about competitors and analogs, user interviews tell you about intent, etc.

But research doesn’t stop with data. Insights only emerge once you spot patterns in data. If lots of people enter the same term into the search box and do not get good results, that tells you something important about your system.

But you can go deeper still. Patterns only tell you what is happening, not why. You should at least have a hypothesis about why things are happening. This calls for understanding the underlying structures and the mental models that enable them.

Collaborating on these levels can be uncomfortable since the work is speculative. Acknowledge the awkwardness upfront. Allow the team to speculate. You’re not making anything normative yet, just understanding why things might be happening.

Knowing causes helps produce better outcomes. You might not know causes precisely, but you can test hypotheses. Ultimately, a better understanding of the system’s structures and underlying mental models will lead to more skillful interventions.

Cover image: NOAA’s National Ocean Survey (CC BY 2.0)


Subscribe to my newsletter

If you find this post useful, you may also like my newsletter. Every other Sunday, I share ideas and resources about strategic design, systems thinking, and information architecture. Join us!

Processing…
Success! You're on the list.

Building Bridges to Understanding

Some tasks are easy, like choosing a flavor of ice cream; other tasks are hard, like choosing a medical treatment. Consider, for example, an ice cream shop where the varieties differ only in flavor, not calories or other nutritional content. Selecting which ice cream to eat is merely a matter of choosing the one that tastes best. If the flavors are all familiar, such as vanilla, chocolate, and strawberry, most people will be able to predict with considerable accuracy the relation between their choice and their ultimate consumption experience. Call this relation between choice and welfare a mapping. Even if there are some exotic flavors, the ice cream store can solve the mapping problem by offering a free taste.

Richard H. Thaler, Cass R. Sunstein, Nudge

Thaler and Sunstein are describing part of what I understand as a mental model. New users aren’t blank slates. They approach interactions with a system using preconceptions shaped by prior experiences with analogous systems.

For example, imagine you encounter chocolate as a possible ice cream choice for the first time. (I know, it’s inconceivable. Everyone loves chocolate ice cream. Right? I know I do. Please bear with me.) If you’ve had chocolate candy and any other kind of ice cream before, you may have a rough idea of what to expect. Chocolate has a particular flavor, and ice cream is sweet, cold, and creamy.

Now consider an exotic ice cream flavor such as green tea. You may have had ice cream and green tea before, so you have reference points for both. However, your prior experiences confound your expectations of how green tea ice cream will taste and feel. Ice cream is sweet and cold; green tea is bitter and hot.

So, when choosing between chocolate or green tea ice cream, you’ll have a better model of the former. That is, your expectations of the taste of chocolate ice cream map more closely to your experience of eating it. If you’re feeling adventurous, you may pick green tea anyway. But it’s a gamble. Hence, those (obnoxiously small) free sample spoons in ice cream shops.

The primary function of information architecture is establishing meaningful distinctions. These distinctions appear as choices to users. Users understand those choices in relation to other choices (i.e., as sets of concepts) and in relation to prior interactions with similar choices (i.e., as individual concepts.)

Some of these concepts will be more obvious than others, much like chocolate is a more obvious choice of ice cream flavor than green tea. Users need help when choosing between unfamiliar or ambiguous concepts.

In other words, users need semantic analogs to those free ice cream samples. For example, each choice could include a clear label, plus an icon or a short phrase that clarifies its meaning in this particular context. Ideally, such aids give users a high-level preview of what they can expect to find when they choose that option. (I.e., they “give them a taste of what’s to come.”)

Much of the craft of IA consists of orchestrating the expectations of users as they’re inducted into new systems. This requires building nuanced bridges between users’ (imperfect) mental models and systems’ (complex, unfamiliar) conceptual models. When done successfully, a user‘s confidence in making choices will increase as he or she interacts with the system.

Cover photo: Ruth Hartnupt (CC BY 2.0)


Subscribe to my newsletter

If you find this post useful, you may also like my newsletter. Every other Sunday, I share ideas and resources about strategic design, systems thinking, and information architecture. Join us!

Processing…
Success! You're on the list.

Overcoming Objections to Modeling

Recently, I asked on Twitter,

What’s the best objection you’ve heard to making conceptual models as part of the design process?

A lively discussion ensued. Some respondents were unclear on what I meant by “conceptual models,” which speaks to the lack of mainstream awareness of this crucial design artifact. (Here’s my latest stab at clarifying.) Others, clear on what conceptual models are, pointed out that the process matters more than ‘deliverables.’ Great point.

But I’m especially interested in the objections. Here are some that represent what I see as the main gist. Chris Avore pointed out that conceptual models are seen as “too hand-wavey or theater-like,” and that they “lead to a few head nods but the world/plan/goal doesn’t change at the end.” To put it bluntly, as Hà Phan did, some people see conceptual models as “bullshit.” (My take: true insofar as they know about modeling at all; I suspect most people don’t.)

Continue reading

Internal Design Teams and Thought Leadership

There’s a sense of disillusionment among some designers about UX’s ‘lost potential’ — that it’s been co-opted for purely commercial (and in some cases, unscrupulous) ends. It’s articulated in this post by Mark Hurst, and I’m reading it into this tweet by Jesse James Garrett:

I haven’t experienced this malaise myself. (But I’ve seen lots of it on Twitter, a platform that rewards kvetching.) Most designers I know are engaged with their work, and my students seem excited for the future. So, I suspect Jesse’s ‘more than a decade’ qualifier matters.

That said, I believe he’s onto something. Designers should be ecstatic about our field’s increased visibility and impact, but we don’t seem to be. What’s going on? I responded to Jesse’s tweet with one possibility:

Continue reading