Copy
Considering labels upfront, plus Mike Rohde on sketchnote thinking & other things worth your attention.
INFORMA(C)TION — June 26, 2022
Considering labels upfront, plus Mike Rohde on sketchnote thinking & other things worth your attention.
Hello! I'm Jorge Arango and this is INFORMA(C)TION: a biweekly dose of ideas at the intersection of information, cognition, and design. If you like this email, please forward it to a friend. And if you're not subscribed, sign up here. Thanks for reading!
A label on a tree branch
Photo by Helena Hertz on Unsplash

Last week, I got an email from Airtable with the following subject line:

Introducing a new name for apps: “Airtable Extensions”

The message elaborates:

Starting today, you’ll see the term “extensions” used anywhere you’ve previously seen “apps,” including your in-base dashboard, the marketplace, and more.

The gist: all of these terms — extensions, in-base, dashboard, marketplace — describe important aspects of Airtable’s product. They represent distinctions you must understand to use Airtable effectively. The company is announcing a change to one of these labels and wants to ensure users aren’t confused.

Product teams are responsible for ensuring products provide features and functionality so users can get stuff done. Naming system elements so people can grok them is essential to that responsibility.

Learning to use the product entails learning its particular vocabulary. Some labels are more understandable than others. I know what a dashboard is, but I’m less clear on “in-base.” The term suggests a crucial distinction (is “out-of-base” a thing?) in Airtable’s structure — one I must surely learn about.

In changing apps to extensions, Airtable does more than replace a word: it’s also changing the feature’s framing. “Apps” suggests more independence from the main product than “extensions,” which merely expand the product’s capabilities. You understand the feature differently depending on what it’s called.

Changing the name of a major product feature or component is not trivial. Beyond the work required of the product team — designing and implementing new screens and flows, changing documentation and training materials, etc. — there’s also a high cognitive cost to the product’s existing (and most loyal) users.

While it’s natural for products to change over time, you want to label things well upfront. Clear, cohesive, logical labels help users figure out what they can do and how they should interact with the system. They make the product easier to learn.

Alas, labels are often an afterthought. Often, product teams name features in ways that make sense to them. (But even worse, I’ve seen developers naming features to reflect how the system is built — a sure recipe for confusion.)

The obvious problem with this approach is that most product teams have more expertise on the subject matter than users. Research helps, of course. But research often focuses on particular features and functionality and seldom on the product’s broader conceptual domain.

The deeper issue is that teams don’t consider labels systematically. Instead, they name product features as the need arises, reaching for whatever comes to mind, and often under time pressure. The problem is aggravated if products or features enter the portfolio through acquisition, bringing into the fold their particular ways of describing things.

(I’m not suggesting any of this happened to Airtable; it may be that their product teams carefully considered the term apps and later changed their minds. It happens.)

So how do you develop effective labels? You do it by

  1. understanding how users think and talk about the subject domain,
  2. understanding how you want users to think about the system, and
  3. defining a conceptual model of the system’s components that bridges 1 and 2.

This can happen at the beginning, when you're starting to define the product. But you can also do it at major inflection points in the product's lifecycle, such as an acquisition or redesign.

You may protest that this is contrary to agile methods and that you don’t know exactly how the product will be structured up front. Yes, this is often the case. But I’m not suggesting you design the whole thing in one go; merely that you consider the system’s primary distinctions, how they’ll relate to each other, what you’ll call them, and that you make decisions about the system’s framing and metaphors. It’s an exercise in information architecture, and it should happen early in the design process.

Yes, you can change your mind later. After all, the product will either evolve or die. But having a sense of how the big pieces fit together — and what users will call them — makes a big difference.

If you haven’t done so already, consider modeling the product’s main components from the user’s perspective — the differences between components, how they work with each other, and what they’re called. Interacting with this model is what using the product is all about — and clear labels make all the difference.

A reminder: if you or your team want to learn more about information architecture, a month from today I'll start teaching a six-week workshop on the fundamentals of IA. Spots are limited; sign up now.


IA:WTF? Information Architecture: What’re the Foundations? Online workshop July 26 - August 30, 2022
Photo by Javier Allegue Barros on Unsplash

From my blog

Finding stuff in digital whiteboards
I like collaborating using shared digital whiteboards. But after a while, it can be challenging to find stuff in these systems.

Automating Jekyll builds and deploys
I recently implemented a new, more effective, workflow for building and deploying my website.

Book Notes: “The Dream Machine”
Overview of a biography of J.C.R. Licklider, which also covers the development of crucial technologies such as PCs and the internet.

Also worth your attention

Strategy and clarity
John Cutler on why many product teams lack clear and coherent strategies. Part of the problem: they “confuse clarity/coherence and certainty.”

Performative design
Sahadeva Hammari: “Design has become intertwined with the most harmful dynamics of the social web.” So many people confuse design with surface-deep style — the antithesis of information architecture. This post argues that focusing on aesthetics snares designers in mimetic traps.

Social media harms
Is social media harmful to society? There are no clear answers. (For my part, I find considerable value in Twitter, LinkedIn, and Facebook. We get out of these systems what we bring to them.)

Amazon search challenges
Finding stuff on Amazon is increasingly difficult. And it’s not just because of poor information architecture; it’s also a case of misaligned incentives. (WSJ subscription required.)

The crux of strategy
How to address gnarly challenges, in three words: discernment, addressability, and focus.

“Game feel” in product design
From the “Craft of IxD” dept.: How to make the world’s most satisfying checkbox. (H/t John Gruber)

Architecture & politics
Oldie but goodie from Mitch Kapor: “the basic insight that freedom, participation, creativity, and openness are better fostered by a decentralized but coordinated architecture, than by a centralized, hierarchical one, remains correct, and is there to be taken advantage of.”


Tweet from @SharadBishnoi05 that says: 'Wish for contextual UI & UX that’s adaptive, agile and scalable? Ensure Information Architecture is not messed up at inception. Most of the solutions, including digital, fall in this trap of quick rollouts that have short terms gains on mind.'

The Informed Life with Mike Rohde

Episode 90 of The Informed Life podcast features a conversation Mike Rohde. Mike is a designer, teacher, and illustrator — but you’re more likely familiar with his work in sketchnoting. Mike is the author of The Sketchnote Handbook, which popularized the practice, and the founder of the Sketchnote Army, a showcase of sketchnoters and their work.

Given sketchnotes’ popularity, I wanted to understand how Mike’s approach to visual note-taking has influenced his work. Besides explaining how he takes notes using a bullet journal and in group co-creation settings, he also shared how taking notes visually has made him a more mindful note-taker in general.

I’ve long been a fan of Mike’s work; it was a real treat to talk with him. I hope you get as much value from this conversation as I did.


The Informed Life episode 90: Mike Rohde

Parting thought

“The day you teach the child the name of the bird, the child will never see that bird again.”

— Krishnamurti

Thanks for reading! 🙏
P.S.: If you like this newsletter, please share it on Twitter or forward it to a friend. (If you're not subscribed yet, you can sign up here.)
This newsletter may contain Amazon affiliate links. I get a small commission for purchases made through these links.






This email was sent to <<Email Address>>
why did I get this?    unsubscribe from this list    update subscription preferences
Boot Studio LLC · P.O. Box 29002 · Oakland, CA 94604 · USA