Author: Andrew Hinton
Reading Time: 7 min 30 sec
Summary: Choose your words carefully: the success of your digital environment depends on the clarity of the language you use for your semantic building blocks.
[For an updated take on this topic, see the post about my 2014 IA Summit presentation.]
As organizations become more dependent upon software—and especially pervasive, cross-channel technologies—they’re learning a hard lesson: language is literally part of the architecture in which they do business; the way they use language is just as important as the structure of their IT systems, management matrices, and even their buildings. In fact, it’s an underlying driver behind all those infrastructures as well.
Like other infrastructure, language is stuff we’ve added to the world that helps us accomplish things together. It’s wider, deeper, and older than the “information” part of “information technology.” Language is and always has been the primary interface between people, as well as between people and complex systems.
Obviously, the building blocks of your company’s content are made of language: advertising, marketing, public relations, product descriptions, instructions. And your internal communications rely on it for things like training, managing, or employee development. Language is there as the actual writing, sure, but it’s also there as the metadata used to structure all that content for publishing, finding, and relating to other content.
Yet language isn’t just essential to content such as documents, articles or ads. Language is also what we use for describing and actually creating products, services, user-facing software, and back-end technologies. When customers navigate your website, search for your products, or try checking out of your e-commerce store, they’re doing those things in frameworks made of labels, connections, and rules—all of which are made of language.
When your systems architects plan your data environment, they’re relying on language to clearly define entities and attributes. When Marketers are naming new products, when Agile teams or Business Analysts are writing user stories or requirements, the language they use ends up shaping outcomes far in the future.
What Can Go Wrong
As with all important infrastructure, if we don’t continually work on its coherence, integration, and maintenance, language tends to get out of hand.
Areas of the company struggle to communicate, collaborate and gain consensus, because they’re essentially speaking different languages.
Projects can go for weeks or months with participants assuming that if you’re using the same words, you’re talking about the same things, only to discover major disconnects and fractures in the project outcomes.
Many hours are burned in meetings that feel like “Who’s On First?” routines, swirling around fuzzy semantics rather than moving forward with work.
Informally disjointed language use trickles into the vocabularies used in systems themselves—from databases to interfaces—hard-wiring confusion into company technology.
Customers are befuddled when trying to understand the meaning of terms they encounter in forms, websites, and phone calls—ultimately feeling lost in a verbal hall of mirrors.
Content is conflated or left unstructured, crippling the organization’s ability to use it across channels.
The places we make with information have unclear boundaries, unstable composition, and torturously crooked paths connecting them.
These issues become even more critical when software and other products or services—including physical places, from stores to airports—have to work together as a coherent, clear system.
Think about the number of hours you, your customers, coworkers and employees spend working in software environments. Think of the percentage of conversations, collaborations, and transactions that happen through digital screens. And then think of how dependent on those systems everything else is becoming, from shopping in a physical store to traveling by plane, train and subway.
Example 1: The Airline Loyalty Funhouse
Consider airline loyalty programs. Each airline has a vocabulary for loyalty levels, and each level comes with certain benefits. Even seasoned flyers may remember what it felt like to first encounter the overwhelming vocabulary stew of air travel. Airlines don’t make it any easier, requiring customers to learn even more “branded” language that’s supposed to communicate the structures in which the customer is trying to accomplish air travel.
But in the last ten years or so, it’s gotten worse as airlines are experimenting with all sorts of tweaks and adjustments to their loyalty programs, offering previously bundled services as enticements and rewards. Every new program spawns a different hallway in the loyalty-program funhouse, where the business rules are so disorienting, it’s often hard to tell which way to turn.
What’s the difference between “Priority, “Premiere” and “First Class”? What’s a “Preferred” seat versus an “Economy Comfort” seat? What’s a “mile” and is it different from a “qualifying mile”? Is it a measure of actual distance flown? (The answer: Yes, sort of, but not really…it depends…) Never mind trying to figure out how all this relates to the loyalty-like benefits you get with a branded airline credit card.
If you know the answers to the above questions, you’re probably an experienced traveler, but I’d wager you still get tripped up from time to time. These terms may sound like mere labels, but it turns out labels are important. They serve as markers, avatars of a sort, representing whole concepts that have been made into structures, procedures, and systems.
Rather than something tacked onto a new service by a Marketing team, labels should be treated as an essential element of the entire service experience, from the reservations system to the physical boarding queues in airports. The labels and the concepts they represent were designed as add-on features, not parts of a coherent, understandable system.
Example 2: Will the real “Group” please stand up?
Especially as organizations grow or acquire other companies or services, language starts becoming more fragmented and contextually ambiguous.
In Google’s Gmail, you can create “groups” of contacts that are basically shortcuts for sending a message to more than one person at a time.
That feature is present in Google’s email product for businesses as well, as part of its Google Apps platform. But this feature was extended to also allow listserv-style mailing lists, and these are also called “Groups.”
Additionally, Google added its Usenet-News-like service (acquired from DejaNews) to the Google Apps for Business platform—and it’s also called (you guessed it) “Groups.” The result?
As an administrator, it’s hard to know what permutation of “group” you’re actually managing.
As an end-user, it’s not always clear if an email came from a mailing-list group or a “Google Group” or what those things mean in terms of sharing a message, following a thread, or finding content later.
Searching for help on anything related to Groups is a shell game, where you’re never quite sure if you’re learning how to administer settings or permissions for the right species of “group.”
Even though Google Plus avoids the ‘group’ confusion by using “Circles,” they’re still essentially groups of people, and there’s still a mystery as to how they relate to the rest of the Google ecosystem, or even if they should.
As with the airline example, here a company is growing its service ecosystem by adding on new capabilities and features, but not considering how the language is the interface to the technology. The engineering underneath all these functions may be pristine, but the experience starts breaking down at the point where humans are trying to understand the overall architecture of the service environment—where they are in it, and how to use it.
Determining the Nature of the Thing
So what can be done? It may be tempting, based on the examples above, to say “let’s just re-label everything!” But the labels added after the fact are ultimately more a symptom than a cause.
A label is deceptively small, like the outside of Doctor Who’s TARDIS: open it up, and you find a whole, large world of complexity inside. The labels are important, but often the root issues have to do with how these services were conceived, defined, and articulated before they were even launched.
There’s a crucial question that every team should ask before embarking on adding new stuff to the world: What is the nature of the thing we are trying to make? This may sound overly philosophical or ethereal, but it’s actually the most practical question anyone could ask.
What if airlines had conducted conceptual planning that approached the whole loyalty ecosystem with the question, “How can we turn our existing loyalty structure into a more flexible system that can scale with new features for the long term? … How can we diversify what we mean by ‘loyalty’ but maintain a clear, coherent relationship structure with customers?”
Or what if Google had asked itself, “What are the ways in which people use ‘groups’ of any kind online?” and, “How can we map to those patterns as we launch or acquire new services?”
In both cases, people would have to reach across organizational silos to engage in conversation, discussion, debate, and ultimately definition. They would have to participate in determining the principles for the overall architecture of the environments they’re shaping.
By principles I mean definition of the essential qualities of something, not a brainstormed list of features. It’s the difference between saying, “let’s copy our groups product and make it available in our business platform” and saying, “what are the essential qualities of the business platform versus other social-application platforms, including how people interact in groups?” These principle-level questions get at the heart of “what it should be,” and form a better foundation for determining a less-arbitrary list of “things it should do.”
And guess what? This work of principle definition is done with language. It generates the primordial DNA for everything that will come after—except it’s done explicitly, on purpose, rather than tacitly, by happenstance. But it requires planning.
Planning is Making
Lately, the idea of “planning” before “making” has fallen out of favor. In software design circles, there’s a lot of emphasis on getting to a prototype or “working software” as quickly as possible. People have the idea that “just talking about it” while making scribbles on a whiteboard isn’t making anything of value yet.
There’s a lot of wisdom in the desire to get our hands dirty early on. But the trend of late is, I fear, an overcorrection. Look at pottery, one of the oldest crafts for making products. A potter doesn’t just throw some clay on a wheel and start “prototyping” something to discover what it should be. Depending on what the piece is to be used for, a potter may need a different sort of clay, or to prepare a particular kind of glaze. It may not even be something that requires a potter’s wheel at all. Even for a craft where the maker quite literally “gets her hands dirty,” there are considerations to explore and principles to decide upon, even if it only takes a few minutes.
If we re-frame “just words” as instead “language is infrastructure,” we see that we’re not just talking. We really are making. Because, when done well, this kind of planning does the hard work of forging a shared understanding that frames the problem and models the driving principles behind the eventual solution.
So, let’s respect the power of language to shape the world around us. Let’s agree that it’s important to “come to terms” with the nature of what we want to create. And let’s take seriously the very real, tangible effects of the semantic building blocks we put into the world, from taxonomies and tags to signage, process models, and org charts. Such a foundation helps form clear structural joints for place-making and sense-making, cross-channel coherence, and “making the complex clear.”
Header graphic created with Wordle.