Language: The Ultimate User Interface

Language is the tool we use to filter and define the world. It’s our first and most powerful tool, and separates us from the armadillos of the world. Language enables us to make connections, build complexities, and to influence each other.

It also has the power to divide us: it crystalizes our differences, and helps us antagonize and irritate each other.

Even in its distilled form (commonly known as “content”) language is often under-estimated, under-valued, and under-funded. How many times have we seen companies import bland, cheap information instead of hiring talented, knowledgeable writers to write fresh, original, interesting content? (Why are editors the second ones to go — right after the writers?)

Why do we — as web-builders — overlook even the most basic aspects of language so frequently when we build our sites? Is language so transparent in our lives that we fail to recognize its importance? Do we even think about it at all? If we do, who manages the language in our sites?

Too often, the answer is “no one.” No one manages the language from a global level, but a lot of people decide what the language will be for specific parts of the site. This is problematic on multiple levels.

It is difficult to ensure consistency — of tone, of terminology, of word-choice — throughout the system without a watchdog who maintains and enforces language standards. This Language Czar could be an editor, a business architect, a user interface designer, an information architect, a copywriter — or come from any of a number of other disciplines.

Sometimes the Language Czar is an autocrat: her word is law. In other cases, she is simply the watchdog, enforcing and normalizing the language decisions made by a group of people.

She’ll have to cooperate with just about everyone working on the site, but most especially the people producing content for the site (including help, guidance text, and error messages) and the people designing and implementing the user experience.

Language is a critical part of the site metaphor, the user interface, and the user experience.

The typical Language Czar will debate synonyms, review word choice, determine punctuation, and establish requirements. She will be asked, “What’s the difference?” and “Does it really matter?”

She’ll build vocabularies, write standards, develop requirements, and review the implementation.

She will also shine a spotlight on some key areas that are often cursorily handled.

Guidance text is a tricky thing. Too much of it can mean that you think the user will be unable to use the site due to his idiocy or your incompetence in designing and building. A user who doesn’t get enough guidance on a page can become lost, or fail to achieve his goals (or yours).

Error messages are even trickier. Some sites don’t even bother, relying on the web or application server to throw up its standard — and uninformative — messages. A good error message tells you what went wrong, why it happened, and what you can do to fix it (if anything).

Punctuation is one of those areas few people think about. You come to the end of a line and boom! Punctuation. There are pitfalls here, too. Do you use quotation marks to set off special things that you or your clients have defined, or does that evoke the sarcastic, much-mocked air quotes? When do you use the exclamation point?

I was once at a user acceptance dog and pony show, and a gentleman who spent his day in the hurly-burly of Wall Street approached me. “Why do you yell at me whenever my searches fail?” he demanded. I stared at him blankly, and quickly asked for more information.

It turned out that an exclamation point at the end of some error messages made him feel like he was being castigated, and he didn’t like it, particularly since it followed the instructions designed to tell him how to get better search results.

Another key area of concern are the terms used to describe the functionality of the system. There are many sites that will rename their “shopping cart” with a cutesy topical monikker, but won’t bother to clarify their menu items.

What’s the difference between “order” and “invoice”? Although some sites treat them exactly the same way, “Find”, “Browse”, and “Search” do not mean the same things. They each have distinct connotations for the user.

I once had a client who explained his dissatisfaction with his previous developers: “I go to Search Here…” he said clicking on a button, “and I look around and I can explore directories by name, but I want to search for this report! It says Search, and I want to search!”

What is the message you want to convey?#section2

Somewhere out there, someone’s asking, “Language Czar, project roles, enforcing… What’s this mean to me, and my one man show, anyway?”

The things you have to think about remain the same whether you are building the world’s biggest trained flea supply store on-line, a non-profit organization’s site, a collaborative space, or your own personal egofest.

What is the message you want to convey? How do you want to convey it? In order to answer those questions, you need to understand who your audience is, what they will get out of the site, what you want of the site, and how it will reflect its proprietor.

We commonly spend huge chunks of time defining a technical architecture, implementing whiz-bang back-ends, and designing the graphical user interface, but rarely do we sit down and think about the language we use to describe the site, its functionality, and its offerings.

Let’s look at a case example. My brother recently put up a website, and was immediately hounded by a pack of relatives because of the spelling errors, odd punctuation, and grammar problems that run rampant throughout the pages. He didn’t see what the big deal is; he expected us to just look past those things to the pet-glorifying content within.

Friends of mine who clicked through his site out of curiosity, however, frequently didn’t make it that far. “How old is your brother?” they asked me. “I thought he was an adult.” People who left the site thought he was an idiot.

He didn’t understand significant portions of his core audience: his family includes an English teacher, a former copywriter, and a cartographer. For weeks, he grew increasingly irritated at the familial email that dwelled more on the language of his site than it did on the content.

He should have been tipped off by the first set of feedback that focused on the language, if not by the experience of living with us for so many years. Instead, he was lucky enough to receive the stream of corrections from his family.

Earlier this week, my brother sent me an instant message outlining his plans to make the site more “user-friendly.” The first thing on it was the language fixes. My mother will be pleased.

Tone is a core part of the user experience#section3

Language can mean the difference between ease of use and user irritation (or worse). The tone of a site can make or break the user experience. It can be the powerful underpinnings of a user-friendly site.

Language is extraordinary flexible, allowing you to establish different tones, vocabularies, and styles to meet your needs regardless of what they may be: a great site that provides information about world hunger will sound and feel different from a great site that sells skateboards to teenage boys.

Take two sites with similar goals: a community built around individual voices. Two such sites, like the Fray and Epinions.com, can have very different tones — and they do. The Fray, wrapping its own unique personality around each individual voice, creates a hip, communal voice that attracts great writers and people with something to say.

Epinions.com takes a different approach, using its site language to set off each opinion or set of opinions, much as fine setting brings out the beauty of individual jewels (or of the metal itself).

Tone is a core part of the user experience, and these sites succeed because the site language has been thought out, planned, and managed. We should all be so successful.