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!
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
understanding how users think and talk about the subject domain,
understanding how you want users to think about the system, and
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.
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.
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.”
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 day you teach the child the name of the bird, the child will never see that bird again.”