A version of this post first appeared in my newsletter. Subscribe to receive posts like this in your inbox every other Sunday.
A couple of weeks ago, 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.