Research

The Key to Understanding Why Things Happen

| Jorge Arango

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.
The iceberg model. Image: ecochallenge.org
Image: ecochallenge.org

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!

By clicking ‘Subscribe,’ you agree to share your email address with me and Mailchimp to receive updates. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Don’t Subscribe; Follow

| Jorge Arango

Per a report in Podnews (via The Loop), starting with iOS 14.5, Apple will remove the word ‘subscribe’ from its market-leading Podcasts app. In its stead, users will be invited to ‘follow’ podcasts. With this change, Apple joins Spotify, Audible, Stitcher, and Amazon Music, which already give users the option to ‘follow’.

Why the change? A researcher claims 47% of people who don’t listen to podcasts think ‘subscribing’ will cost money.

This is a great example of the sort of counter-intuitive insights one can glean from research. I’ve never been confused by the word ‘subscribe’ in this context. Given the choice between ‘subscribe’ and ‘follow’, I’d argue that ‘subscribe’ is a clearer description of what is happening.

But I understand how podcasts work. Many people don’t, and I can see how they’d understand subscriptions — an action they likely associate with newspapers and magazines — as something they must pay for. While less precise, ‘follow’ is a familiar enough term (especially online), and one that may be less intimidating.

‘Follow our podcast’: Apple Podcasts to stop using ‘subscribe’

The Expertise Trap in UX Critiques

| Jorge Arango

From an article in TNW about the UX of posting and commenting on LinkedIn:

As haphazard as lots of the design is, there does appear to be a goal: driving up in engagement. That makes sense, but where the real joy comes from is the batshit way this is approached.

The article highlights two features ostensibly designed to drive engagement: LinkedIn’s canned responses, which, according to the author, have produced “a terrifying world filled with reams of identikit comments that come across as inhuman and deeply insincere,” and its “add hashtag” feature. Most of the article focuses on the latter.

Continue reading →

Understanding Customer Mental Models

| Jorge Arango

How well do you understand your customers? Do you know how they make decisions? How they see your business’s domain? What makes them tick?

Everyone understands things a bit differently. Nobody has a perfect, complete understanding of the whole of reality. A neurosurgeon may understand the human nervous system but be unable to successfully configure the security settings of her smartphone. Knowledge of one domain doesn’t necessarily translate to another.

You carry around in your mind internal representations of how things work. These representations are called mental models. Wikipedia has a “good enough” definition:

A mental model is an explanation of someone’s thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person’s intuitive perception about his or her own acts and their consequences.

The more accurately these representations mirror the way things really are, the more skillfully you can act. If you understand the distinctions between the components that define your phone’s security and how they relate to each other, you’ll be able to make good predictions about the consequences of your decisions.

Forming good mental models for complex domains isn’t easy. Modeling calls for thinking in abstract terms. You may be tempted to apply a model from one domain you understand well to another you don’t. (E.g., “I bet this works just like x.”) We aren’t formally trained to model the world. Instead, we form mental representations ad hoc, filling out the broader picture as we go along. Thus, we have imperfect models of much of reality.

Ideally, you want your customers to have good mental models of your business’ domain. This is easier to do in well established domains than in new ones. For example, more people are likely to have good mental models of the process of renting a car than securing their smartphone.

It’s important that you understand your customers’ mental models for your domain. This isn’t something you can ask them about in an interview. We don’t express our mental models overtly. Instead, they manifest indirectly in our actions. What to do?

One way to go about it is to observe them interacting with prototypes and making note of how they interpret its major concepts and their relations to each other. Another is to engage customers in co-creation sessions to design solutions for the domain.

In this second approach, we don’t expect the solutions that emerge to lead directly to products or features. Instead, the artifact functions as a MacGuffin that allows us to map the customers’ mental models of the domain. This approach is especially useful in early stages of the design process, when we don’t yet have a prototype to test.

With a better understanding of how customers see the domain, we can design solutions that allow them to make more skillful decisions. This may call for producing means for them to adjust their mental models to more closely align to reality. Or it may require that we adjust the system we’re designing to better match the models users bring with them.

In either case, we’re not starting from a blank slate: we must meet people’s understanding of the domain. This requires that we understand their mental models.