Think of the verbs we use when describing the work we do on digital products: develop, design, code, manage, test, release, launch, support.
You’ll note, though, that we don’t often say that we write web sites or apps. “I write web sites” isn’t a sentence we hear nearly as often as, say, “I design web sites.”
But writing well—that is, carefully choosing and assembling the words in our UI—is one of the most important things a digital product & experience team can do to offer a great product. The text that appears in an interface, in the form of menu options, button labels, page headers, and instructions for users, is critically important to the experience we create and the satisfaction of our users.
Web readers don’t actually read
A dirty secret: few visitors actually read lengthy blocks of explanatory text on web pages. (I’m not referring to destination content, like articles on a news site.) Instead, we skim, looking for what we need, and pausing when something catches our interest. So wherever possible, we should organize copy with brief labels, clear headings and subheadings, and bulleted lists. We should write for someone who is scanning, not reading. For example, we can generally eliminate “permatext,” that ugly, unread paragraph that appears at the top of some web pages to explain what is about to happen. A paragraph saying “This page is where you can find tools and data to see what’s happening in your account” is simply unnecessary: the giant “Account Dashboard” header and the pageful of account information dominating the page told the reader that already.
I like to employ a pony test: if in a block of text I embedded a sentence saying “read this sentence and we’ll give you a free pony,” would you actually give away many ponies?
Most humans don’t speak engineer
Digital product professionals understand that the internet comprises web servers, protocols, markup that’s parsed by browsers, scripts that are run on the client side, databases accessed on the server side. But this technical paradigm can start to leak into the language we present to users. For example, engineers may reasonably think of a search as a query of a database that a user executes by submitting a form comprising filters and keywords. But the user thinks that same search is a way to find the shoes she wants. So while the engineer may think “submit query” is the perfect label for the button on the search form, in the language of the user, the better label is “find shoes.”
A user interface is a conversation
I find it helpful to think of the language in our interfaces like a conversation with a valued guest. If a guest in your home encountered a locked door, you wouldn’t say to her: “This user account does not have permission to access this resource” and then turn and walk away.
You would instead understand that the guest had reasonably thought that this might be where you kept the spare towels. So you might say: “That’s actually a closet where we keep things for the dog. Are you actually looking for things for the dog? No? Can I help you find what you’re looking for?” That’s the way a good user interface should feel: helpful, human, conversational, and empowering the user’s choices.