Starting Points for Better UX Writing - Melbourne Word School · 3. Language 4. Applications. The...

1

© Georgina Laidlaw 2018

Starting Points for Better UX Writing By Georgina Laidlaw

2


INTRODUCTION .................................................................................................... 3

1. PRINCIPLES........................................................................................................ 4 The Process ......................................................................................................................................................... 4 The Process in action ...................................................................................................................................... 6 Setting word design principles ................................................................................................................ 11 In summary… ................................................................................................................................................... 14

2. GRAMMAR ...................................................................................................... 15 Pronouns ........................................................................................................................................................... 15 Passive voice .................................................................................................................................................... 17 Punctuation ...................................................................................................................................................... 19 Capitalisation ................................................................................................................................................... 21 In summary… ................................................................................................................................................... 23

3. LANGUAGE ...................................................................................................... 25 Understanding Reading Level .................................................................................................................. 25 Understanding – and writing with – tone ............................................................................................ 29 Writing conversational interfaces .......................................................................................................... 31 Using accessible words................................................................................................................................ 34 Respectful writing ......................................................................................................................................... 37 Writing for other languages ...................................................................................................................... 38 Colloquial and idiomatic language ......................................................................................................... 39 In summary… ................................................................................................................................................... 41

4. APPLICATIONS ................................................................................................. 42 Combining text and imagery ..................................................................................................................... 42 Onboarding ....................................................................................................................................................... 44 Lists ..................................................................................................................................................................... 46 In-product help ............................................................................................................................................... 48 Product email .................................................................................................................................................. 49 In summary… ................................................................................................................................................... 50

3


INTRODUCTION At the beginning on 2018 I started a weekly newsletter called The Word Design Doctor as way to help designers, product people, and writers understand and learn how to write good microcopy. This ebook is the culmination of that year of work. If you missed the newsletter, forgot to read some issues, or want an indexed copy of the advice organised sensibly, then I hope you’ll find this resource useful. I’ve organised it into four sections:

1. Principles 2. Grammar 3. Language 4. Applications.

The thing to remember, which may disappoint if you’re not a writer, is that you need to have a strong grasp of language to write well. There’s just no way around it. So I’ve tried to make the chapters on grammar and language as straightforward and digestible as possible. As I write this, there are a number of books and ebooks on microcopy writing on the market. But not many, as this is still an emerging field, with no formal qualifications or training recognised for UX writers. Practice and experience and testing are currently the only ways to get objectively good at UX writing. I hope this ebook will help you get the practice and experience to write copy worth testing. Georgina Laidlaw MelbourneWordSchool twitter.com/georginalaidlaw

http://www.melbournewordschool.com.au/

https://twitter.com/georginalaidlaw

4


1. PRINCIPLES

There are a few useful principles or basics that can help your UX writing get better, faster. In this section I’ve included what I think are the keys to good UX writing. First up is The Process: the system I use to develop interface text. That’s followed by an approach you can use to take your organisation’s design principles (assuming you have some) and translate them into word design principles. As we’ll see, this can be extremely informative when it comes to answering other questions of tone and style for interface text. These first two parts should help you to start building a product language style guide if you don’t have one already. Next, we’ll meditate on the importance of brand and visuals in interface writing, which, to me, is as fundamental as knowing how to type. Finally, I’ll give you a tip for the actual process of writing the words that appear in your interfaces. Let’s get started.

The Process This is the process I use whether I have an all-new problem to solve with text, or someone comes to me with a ready-made visual that requires existing text to be updated. Step 1: Context Of course the first question is, what’s going on here? To write good microcopy you need to know the product and the brand, yes and yes, but you also need to know what, precisely, is happening in the interface you’re looking at or designing.

What have users experienced before they got here? You can answer this question in as much detail as you like.

What action are we trying to get them to take? Make sure you’re very clear on this.

What else in the interface is supporting them to complete that action? The answer to this question usually affects my copy dramatically; if you’re a UX designer, you’re in the lucky position that you can change the design to better support the words (or vice versa); unlike a lowly interface writer, you have both design and text at your disposal.

Step 2: Audience My next question is always: who’s trying to use this interface, and why? In what context are they trying to complete this action? How do they feel at this moment?

5


What’s riding on their success or failure? I’m going to let you in on a little secret here: I’m not very creative. Often I find UXers and designers want to make user feel something deeply meaningful when, for example, they tap the “Save” button on a function in a product. I, on the other hand, feel that users generally just want to get things done. Especially with repetitive actions, I personally believe users often feel some level of boredom at the repetition, or perhaps frustration at the wasted time — even when the product is associated with something they enjoy. My message here is: don’t just look on the bright side. Acknowledge and cater to potential negative or neutral feelings, too. But that’s not all. We also need to consider whether the users are native-speakers of English or not. Cultural differences matter to mindset, and ultimately to the words you’ll use too. Step 3: Component specs Writers are often asked to write for specific interface components: notifications, popups, errors, help and more information links. If these are common in your product, you and your colleagues would do extremely well to set some guidelines for the text they contain. Perhaps every warning has a headline and one or two sentences of text. Perhaps the headline can be no more than 30 characters, and the body no more than 20 words. Perhaps the headline will appear in sentence case (rather than title case). Perhaps a warning will always include a link to your FAQs. I encourage you with all my heart to document these requirements and put them into a style guide that you can refer to every time you need to write a message that has to fit a particular format. And if there are already specifications like this that can help guide your writing in whatever instance you’re writing for, you need to know what they are. Step 4: Messaging This is where the fun starts. It’s also the part that I find people generally have the most trouble with. Here, you need to express what you want to tell the user at its most basic. Don’t get all high-falutin’ with your fancy university-degree English. Keep it as low-level and natural as possible. If you’re writing a Save confirmation, the message might be:

Saved. That’s saved. We saved your stuff.

6


Done. We got it.

This is not about linguistic expression; this is about a gut-reaction communications goal. What do you want the audience to know at this moment? Write it as simply as possible. Step 5: Refinement Now is the time get out your brand style guidelines, crack open the dictionary, wheel in the thesaurus, and deploy the big guns of your grammar prowess. It's time to write text that optimally communicates that message to your audience in the voice of your brand at this specific moment in their conversation with your product. Here’s where you hone the words, and make sure they coherently add to (rather than simply repeating) what’s already communicated through other text or visuals on the page. As you write, test the reading level to make sure you’re keeping your text simple. And of course, make sure they communicate consistently in your brand's tone of voice. Refinement takes time. You may well end up with a few options that you want to test. Along with Step 4, Messaging, you might consider completing this step with a colleague or two, so you get a composite of brain power from within your organisation. It’s not always possible, but it’s probably almost always desirable.

The Process in action Okay, now that we understand The Process, let’s see how it might play out in a typical case example. Let’s imagine we work on the VicEmergency App. A colleague has come to us with a problem: users are complaining that the New Watch Zone Alerts page is confusing. Does the wording need work, maybe? Here’s how it looks right now.

https://play.google.com/store/apps/details?id=com.naturallybeing.fireready&hl=en

7


8


What’s the first thing we ask? That’s right: what’s the context? Here it is: the VicEmergency app aims to keep Victorians apprised of emergencies. To that end, it allows users to set “Watch zones” — areas that, when there are emergencies, it would be useful for them to know about. Great, you say … What kinds of emergencies though? What’s the use case? Well, a farmer may set a watch zone to alert her to bush or grass fires in summer. A teacher living in coastal East Gippsland who drives an hour to work in Sale might set a watch zone for floods so that they can take an alternative route when necessary and still get to school in time for class. Good, so we have an idea of our audience. And this Watch zone page? What came before it? Well, the person has tapped Add a new watch zone on the app home page. Then they’ve pinched the zone to the right size on a map. Then they tapped Next. Now they’re on this page. Great, more context. And what specifically are we trying to get them to achieve here? We want them to select the items they will see highlighted in their watch zone — and receive alerts for — when those events arise. Are there any component specs? No, we can do whatever we want with this page, as long as we use the Vic Emergency design styles. Great. Now we need to look at messaging. As we can see, there are a lot of Warnings and Incidents here. We need to communicate that these are different groups of things. Warnings include automatic alerts. Incidents don’t. You can turn Warning advice and Community info on and off, and have the alerts emailed too. But for Incidents, you have more options. To my mind, the difference between Warning advice and Community information is something we might want to try to make clearer, but let’s keep our focus on the bigger picture for now. The question is: what should our messaging be? This page is about the watch zone users have just set, so first of all, we don’t need to refer to “this watch zone” in the text. Beyond that, the list lets users choose the alerts they see, so let’s make that our heading for now. We might also mention they’re in-app notifications.

9


Then, users will want to understand the difference between Warnings and Incidents. There’s a lot of text, and some of it’s repetitive. That’s confusing. The listings suggest two key messages:

1. We’ll tell you if you need to (or might need to) evacuate your watch zone.

2. Choose any events you’d like to know about before you need to evacuate.

Actually, the structure of the list itself seems to say that pretty clearly. What would happen if we took out the sections and text? The layout over the page. Is it perfect? Of course not. But this isn’t a bad time to get a colleague to look at what we’ve done and (inevitably) tell us why we can’t do it this way. One reason may be that other screens of the app differentiate between Warnings and Incidents, so we’d have to see if that language was necessary there, too. That’s fine — whatever our colleagues tell us will help us work out what actually needs to be said in text on this page. Through this process of reiteration, we’ll arrive at some nice, concise text that gives people what they need to know to get this done right.

10


11


Setting word design principles The web’s gone design-systems crazy. And it’s great, for all the reasons you already know: consistency, simplicity, efficiency, branding, respecting the user, and so on. But where does UX writing fit into your brand’s design system? Well, the first thing we want to acknowledge is that everyone’s design systems are different, as they should be. Great. What that means from a UX writing perspective is that your organisation’s design system may or may not include writing guidelines. Shopify’s Polaris, for example, has extensive content guidelines. Trello’s Nachos, on the other hand, focuses on visual, rather than linguistic, communication. Let’s imagine your organisation has a visual style guide or a design system, but one that has nothing to say about text. The question here isn’t, “Should we use an Oxford comma?” or “How do we style times and dates?”, but “Where on God’s green earth do we begin?” Having been faced with this conundrum a few times, I have an idea: start with your design principles. Why? Because visual/experience/interaction design naturally involves text. The two have to work together. So if we remove the “slick visuals” element from our understanding of the word “design”, we can see that design principles cover everything that’s included in your product or experience, from structure and logic right through to those pesky time and date stylings. So how do we make sense of design principles in the context of, er, text? Let’s look at Polaris. The design principles are:

put merchants first empower but don’t overwhelm build a cohesive experience be polished but not ornamental.

And the writing principles read:

respond to merchant needs encourage action be consistent write for a grade 7 reading level.

They’re a little more pragmatic as guidelines than the design principles were, but you can see how closely they parallel the design principles. In some cases, they seem merely to have been rewritten in different words, but in others they speak specifically to text requirements. You might like to do that, or you might like to keep your principles broader and more “principle-y”. Let’ see how that might work with Nachos. It says Trello is:

https://polaris.shopify.com/

https://polaris.shopify.com/content/product-content#navigation

https://design.trello.com/

https://design.trello.com/principles

12


Universal Easy Personal Visual and tactile Familiar Succinct Direct Flexible Collaborative Fun

Wow! Long list. If you read these principles in detail, you’ll get a very clear view of the approach Trello takes to bringing real-world concepts into their digital environment — an approach which seems central to their brand and product. That said, I personally feel the labels given to these principles don’t very clearly reflect the meanings of each description (e.g. "Easy" talks about clarity, but ease and clarity are not the same thing). Also, there’s a mix here of principles (general overarching guidelines about approach) and styles (specific directives on the application of particular language techniques). So, if I was to reinterpret these into word design principles, the list might look like this:

Universality: Speak to everyone. Tactility: Use the real world as your starting point for text. Clarity and simplicity: Use simple words and phrases. Don’t use or

invent jargon. Flexibility: Avoid implying how Trello “should” be used. Let the user fit it

to their needs. Collaboration: Communicate a context of team work in all languages

offered. Personality and fun: Respect each user, and Trello, as an individual.

Embed the Trello personality (friendly, witty, light, helpful). I know what you’re thinking: that list is pretty short all of a sudden. That’s because, as a writer, I need to quickly understand the emotional and practical context of a product I’m writing for. Less is more when it comes to writing principles. And clarity is key — I really think the Trello principles are a little confusing. Here, in case you’re interested, is my thinking on each one. Universal This design principle is focused on the product’s utility. To support that, I’d argue that text must speak to everyone. That means plain English and writing at a low reading level, for native-speakers and to support easy translation. Easy Although it says “easy”, this principle in fact talks about product clarity. Clear language is a no-brainer text principle.

13


Personal This principle focuses on the user perspective or lens. In the world of text, what comes after “personal”? Why, “pronouns”, of course! Some style guidelines about using personal pronouns would be a natural fit under this principle. Visual and tactile, Familiar These two principles speak to the real-world visual references that Trello uses to help users feel comfortable, natural and at home in the product. We can do the same with language, via guidelines on using plain English and avoiding jargon or “cool” terminology. Succinct This speaks directly to text as it does to visual and interaction design, and in fact the description begins, “There’s little Trello product vocabulary to learn.” I think that’s more about familiarity than succinctness, so here I’d make a style guideline about using short phrases, rather than sentences, wherever possible. Direct This principle is about reducing interactions to the minimum necessary to get tasks done. I’d translate this into style advice to use present-tense verb forms and the active voice. Flexible This principle already indicates that the flexibility of the product precludes the use of language that implies a certain application for elements of the design. Collaborative In terms of language, this would indicate the use of some stylistic techniques we’ve already mentioned: simplicity, personal pronouns, low language level. It might also indicate an approach to notifications about collaborator actions. Fun There’s some tone information on Trello here: “It's friendly, witty, light, and helpful. We delight members with little big details that make all the difference.” Keep your text design principles simple. (Ideally, also keep your design principles simple.) One thing to keep in mind is the difference between principles and styles. To my mind, they’re very different. Principles are the guiding lights that illuminate the landscape in which you’re writing — a landscape that includes user goals, business goals, audiences, and your brand. Styles are specific directions on using certain words or grammatical conventions to get somewhere in particular. I really think they’re best separated from your

14


word design principles since, ultimately, they show how the principles are applied in practice.

In summary… Hooray! We’ve got the basics we need to know to start systematically writing interface text, and building our skills as we go. Systems are important, don’t you think? I do, which is why I developed The Process we discussed here: to help us take a consistent approach to every piece of copy we write. You’re now in a position to translate your company’s design principles into word design principles, if you have the former but not the latter. This can help you to define tone and stylistic approaches to interface text, as we’ll see in the coming pages. Not bad, friend. What’s next? Well, it’s time to get down on our hands and knees, roll up our proverbial sleeves, and play with the lego blocks of microcopy. That is, words and grammar. Don’t worry: I promise it won’t be too painful. No, wait! I meant it won’t be painful at all! Let’s do it!

15


2. GRAMMAR Great news, friends. Great news! I’m not only a qualified English teacher: as it happens, grammar is my favourite topic! This is how I start my classes each time I get a new group at the school where I teach English to non-native speakers, and you can just imagine the joy with which those words are met. I bet you’re feeling it now, aren’t you? You’re crying on the inside, I know. But trust me: this will be painless. More importantly, it will be immensely useful to you as a UX writer. We’ll touch only on the grammar topics that are particularly important. That is, pronouns, passive voice, punctuation and capitalization. Easy, huh? Let’s do this.

Pronouns Hey you! I mean me. As in you-me, not me-me. Confused? (Me-)me too. And we’re not alone. Even TinyLetter has trouble with forms of address…

Look at those first two checkboxes. They read: Show sent messages on your archive page. Send replies to my email address.

Who am I again? Me-me or you-me? What we’re talking about here is personal pronouns. Reminder: a pronoun is any

https://tinyletter.com/

16


word that we use as a substitute for a noun in a sentence. It, they, he, she, those — all of these are pronouns. A personal pronoun is a pronoun that we use as a substitute for people's names: she, he, they, I, we, us, you. There are also possessive pronouns (your/yours, her/hers, my/mine), and subject and object pronouns (as in the previous example; don't sweat it), but these are less controversial than the question of whether to use first-person (I/my/mine) or second-person (you/your/yours) pronouns in an interface. What’s that? Did I just say “controversial”?! Why, yes. Yes I did. This distinction is so controversial, in fact, that Google saw fit to include an entire section on it in its Material styleguide. The very first section on writing, called “Addressing users”, shows how Google uses pronouns. Whether or not you agree with the distinctions made there, the point is that this is a big deal in a world where we’re trying to create stronger connections with all the yous out there. As we can see, it’s all too easy to get tied up in knots with your mes and Is and wes. So what’s the prescription for avoiding personal pronoun pain? 1. Omit them. My first option is always, always to cut words. Instead of "My Profile" or "Your Account", just say "Profile" or "Account" already! Less is more, right?! Okay, so this may not work in all cases — where an enterprise product has “superusers” who can access the company account as well as their own personal accounts, for example — but it can be a useful solution in many situations. 2. Don’t cross the streams. Google advocates this and, uncharacteristically, I find I must agree. Whatever you choose, don’t use my/mine and you/your in the same space, as TinyLetter has done in the example above. Choose one, based on your house style guide (add to it if you need to specify pronoun usage), and stick to it. Simple, right? Easy. No sweat. So how might we improve TinyLetter’s tiny error? Well my friends, this is where “simple” goes out the figurative window! Predictably, there are more problems here than just them crazy words. Let’s look at the text — specifically, the styling. The “Account settings” and “Notifications” sections use grey text to present options that are framed as instructions to the service. When I check a box, I’m giving an instruction to this product: Send replies to my email address, TinyLetter! But the “Send directly"” section? Hmm. The first sentence is framed as an instruction, but as it turns out after a few synapse misfires, it’s actually an

https://material.io/guidelines/style/writing.html

17


instruction for me! Yes, little old me (or “you”, to you). And, even more confusingly, the explanation that follows this instruction is presented in the same font — same style, same visual weight, same everything. There’s also some weird spacing between these sections which gives me a cue that “Account settings” and “Send directly” are somehow related, although they’re given equal value in the visual hierarchy. What? Let’s just say there’s more work to do here than to simply change “my” to “your” (and to either add a full stop to every single checkbox description on this page, or, if you insist, remove them all). I’ll leave the design possibilities to your imagination. But as you can see here, there are important questions to consider around personal pronouns. Overall, you want to consider using them for the sake of sounding natural and conversational. Beyond that, specify some house styles around how and when they’re used.

Passive voice Next up is passive voice. Or as I like to call it, Robot-speak. To consider the importance of passive and active voice in digital products, let’s take a look at two period-tracking apps. Glow is on the left; Clue is on the right.

Let’s look at Glow first.

https://glowing.com/glow

https://helloclue.com/

18


Prediction updated! This is what we call a passive-voice phrase. Ultimately, the passive voice lets us remove the actor from a sentence. Grammatically speaking, this one includes a subject (always a noun; in this case, prediction) and a verb (updated). But we don't know who or what made that action (the verb) happen. In the real world, people more often talk in the active voice, which is used in the Clue message: We’ve updated your predictions. Users know who’s done the updating here: we, that is, Clue. If passive voice removes the actors, active voice makes sure they’re included. This sentence includes a subject (noun — that’s we), a verb (updated), and an object (the noun which receives the action: your predictions). In the passive voice, the focus is on the thing (prediction) and what happened to it (updated). I’d guess this is why it’s been so popular in digital products to date. Most people working on products agree that the focus should be on the user, not the product or the company making the product. So where the natural-language sentence We’ve updated your predictions puts Clue front and centre, Glow’s Prediction updated! focuses entirely on what the user is trying to do: add information to make their prediction more accurate. So passive voice is great, right? Well, maybe not. Allow me to explain. The philosophy underlying conversational UIs is that a human’s interaction with a digital product should follow the rules of conversation. This is a multilayered challenge, but one simple step in the right direction is, at the very least, to use words that sound conversational, and use them in a conversational way. Passive voice (Prediction updated!) tends to sound robotic. Active voice (We’ve updated your predictions.) is much more human-sounding. As time passes, I’m more inclined to bring the product or its makers (we) more heavily into the conversation inherent in a product, because I honestly believe this: the knowledge that the thing is made by actual people helps reflect a product’s humanity, and that encourages emotional connection among audience members. But if you’d prefer to focus on the user and leave your own humans out of the equation, you can still use the active voice. Below are some examples. Remember, the last line the user saw (during the data save) read, Clue is getting smarter…

Thanks. Your prediction’s updated now. You just improved your predictions. Thanks, that’s done. Keep on tracking.

https://developers.google.com/actions/design/

19


Take care with messaging, though. If you used that last option, the user would only be getting the message that their tracking benefitted Clue, rather than actually improving their own cycle prediction. So you might need to change the Clue is getting smarter... saving message if you wanted to use this confirmation. The more you practice, the better you’ll get at spotting and removing passive voice from the conversation. But it’s definitely something to look out for, and try to minimise.

Punctuation I’ve mentioned a couple of times that punctuation isn't just for looks. thats because punctuation serves a very real purpose among other things it helps us understand not just where sentences start and end but which parts of a message are key and which are secondary just as importantly its critical to our interpretation of written tone Get it? Let’s look at a very typical example where more consistent punctuation styles might be worth trying. It’s from Trade Me, a market-leading online marketplace based in New Zealand.

I’ve included first the desktop, then the mobile views of the login page. We can see here that the Register now call to action at the top of the login area on the desktop site does not have what editors call finishing punctuation (that is,

http://www.trademe.co.nz/

20


anything to mark the end of the sentence). Nor does the Register link on the mobile page. However, all the other links do have finishing punctuation, since all of them are questions, and a question isn’t a question in English without a question mark. (In the desktop version, the checkbox labels lack finishing punctuation also, but let's focus on the links for now.) This is an extremely common trend: if it’s a short, linked sentence, people seem to want to leave off the finishing punctuation … unless it’s anything other than a full stop. But is that a good style? I say no. It’s not a good style. I understand that designers take in many elements when they communicate through design, and that includes things like space, font weight and colour, and so on. A designer might, quite logically, argue that the Register now and Register links are positioned in such a way that they are not going to be confused as part of other text, and their treatment indicates that they’re links. Great! Nice! True! … in this case. So should we add those conditions to the style? That might get a little confusing and convoluted for others to follow. (e.g. What kinds of positioning of short links are okay for the no-full-stop style, and when will we make full stops required? We’d need to specify that.) But then, what will happen in all the other cases? Because you and I both know that there are going to be myriad other cases, and we’re going to have to make this call on every single darned one of them, case by individual, tedious, ugly case. Perhaps there are other cases we haven’t even imagined yet where this style must be applied, but it’s confusing or misleading in practice. Maybe we’ll have to write a separate style for each of those! Or will we? Hell no, we won’t! Instead, we’re just going to make a single-sentence style that says, “Link text is punctuated like sentence text”, end of already-short story. Woohoo! Job done! Style guides are intended to make life easy, and are especially helpful for teams where the work is distributed among different people. So where you can remove complexity from a style guide, do it. That gives you the energy to add complexity where it’s needed, and it gives the guide’s users the energy they need to implement those more complex styles into your product. Link text is, I argue, not a place where complexity is needed.

21


Before we move on, there’s one other thing. Earlier, I said punctuation affects tone. How do the following options sound in your mind when you read them?

Register! Register… Register. Register

Punctuation matters.

Capitalisation Okay, one more topic to go, and by the way, you’re doing well at this grammar thing. Really well. Don’t stop now! Our last topic is good old capitalisation. Now, proper nouns always get capital letters at their beginnings, as we know. But what about, like, other nouns? What about words that aren’t nouns? What even is a proper noun anyway? So many questions. First, as always, let’s see a couple of examples of caps gone awry. The first is SEEK — Australia’s leading jobs marketplace, whose brand is, fittingly, presented entirely in capitals.

After our previous discussion, I know you’ve already clocked the lack of a full stop on the key message on the right-hand page. Now, let’s focus our laser-like

22


attention on the capitalisation. The page on the left is the app Home page. As we can see, everything here is in title case, which means every word has a capital letter at its start, including (conveniently) my self-entered job search for ESL teachers, but excluding the New search “field” (which is actually a link, like all the other blue text on this page). The fact that New search doesn’t appear in title case, even though Saved Searches does, seems weird. Why? Because it's inconsistent. Inconsistency draws our attention, and wastes our energy. Inconsistent nomenclature, or presentation of nomenclature, requires users to learn each new(ish) word as they encounter it, and fit it (again) into their mental model for your product. The more consistent your use of language, the less background-thinking noise the user will experience as they use your product. The page on the right is called My Activity. It has two areas, called Saved and Applied. Or SAVED and APPLIED, if you want to split hairs, which of course I am here exclusively to do. On the SAVED page, Saved Jobs in the body text appears as a proper noun — a name. That’s fine, insofar as any company has the choice to make proper nouns out of whatever product or feature names it likes. The reason I point it out is that the proper noun “Saved Jobs” is not used anywhere else on this page, which feels a bit weird. If the page itself were called “Saved Jobs” then the capitalisation would make sense, but as it is, it raises questions. Why? Well, capitals send a signal to users. They say, This Thing’s Important. So if we see something presented as a proper noun, we expect it to be an established entity — a thing — of some kind. Like The Smiths or a Big Mac or Farenheit. If you’re going to make Saved Jobs a thing, you want to use it consistently throughout your product, your marketing collateral, and your support literature. Any saved job will be referred to as a Saved Job (not Saved, not a saved job, nor a Saved job, nor a saved Job) every single time, everywhere. If you’re not prepared to commit to that, don’t capitalise it. If you are prepared to commit, add it to your style guide as part of your product lexicon: a list of product and feature names whose usage is set in (proverbial) concrete. What about that capitalisation of New search on the homepage? Given the prevalence of proper nouns everywhere else on this page, I’d make that a proper noun, too: New Search. As an aside, that link always looks like a field to me. If it were, and SEEK was using the initial-cap style (that is, capitalising only the first letter in a short string

23


of text) to hint that this was not a link like every other piece of blue text on the page, I’d advise against that approach. Capitals (or lowercase) shouldn’t be used alone in an effort to differentiate the function of an element of an interface. Why not? Because they can’t do that on their own. Users look for other cues to discern the functions of parts of a page. In reality, the New search field on the SEEK homepage has the little magnifying glass to differentiate it from the other links, and this always makes me think the New search link is a search field. But no, it’s a link, like all the other blue text on this page. And when you tap it, you go to a page called Job Search. As Jakob would (probably) say (I’m putting words in his mouth, okay?), short link text like this should lead to a page of the same name — as indeed do all the other links on the homepage. And since “Job Search” may not work as a link in the already job-searchy context of the homepage, “New Job Search” may be worth considering instead. These are the kinds of capitalisation tribulations UX writers must necessarily consider as we work with links and labels. Also, keep in mind that:

Title Case Tends to Look Official and Formal Initial-capped titles read less formally.

Capitalisation influences tone. So, choose a capitalisation style that suits your brand and formalise it in your style guide. Develop a product lexicon as part of your style guide that lists product and feature names, and how they’re used. For example:

Can they be used as possessives (SEEK’s)? Can they be pluralised/singularised (Saved Jobs, a Saved Job)?

Don’t use capitals alone to differentiate the function of text in an interface. And finally, don’t use all-caps — unless you’re SEEK. Be very careful in choosing this as a design style for headings or labels. As the brand name SEEK illustrates, all-caps reads like shouting, or at least very strong emphasis.

In summary… You did it! You got through the section on grammar, and for that, I salute you. We covered pronouns, the passive voice, punctuation and capitalization, all of which are important elements in microcopy. Take a position on each one, and document it in your style guide. At least, that’s my recommendation. It’ll help you remember what you’re doing whenever you need to write something, and it’ll also help your colleagues do the

https://www.nngroup.com/people/jakob-nielsen/

https://www.nngroup.com/articles/link-promise/

24


same, whether they’re on the other side of the room, or the other side of the world. Now we’re talking in consistent in-product language, and that’s exciting! What’s up next? We’re going to look more broadly at how we express things using language, and what we communicate as we do so. I’ve called the next section “Language” because basically, we’re pulling together what we have so far, and seeing what it means for linguistic expression. If you want to call UX writing an “art”, the elements we’ll cover next will likely be critical elements in your practice.

25


3. LANGUAGE You know your user audience. You know your brand and its style guidelines. You know grammar. Here’s where all that comes together. In this section, we’ll look at language. Firstly, we’ll consider our goal as interface writers: to write usable text. We’ll then go on to look at elements of expression, like tone, conversational and respectful language, the accessibility of words, and idioms and colloquialisms. We’ll also consider the challenge of writing in English interface text that is destined to be translated into other languages — and potentially different character sets. There are interesting times ahead. Let’s get into it.

Understanding Reading Level Reading level seems to be something that many people writing interface text are yet to get a handle on. It surprises me, because using reading level scores to assess my writing improved my work dramatically in a short space of time. Perhaps they could help you, too. Readability scores rate the reading level of the text you write. Thus, they help you to make your writing more readable, and thus more usable. It’s that simple. So if you're not yet on board with them already, today’s the day to embark. I’m not going to bore you with the story of the scores — Wikipedia has everything you need to know about how they’re calculated. The point is that good old Word provides a Flesch-Kincaid Reading Ease score and a Grade Level score on every piece of text you spell check. So do other writing apps, like Hemingway. As an example, let’s take some text from Australia’s MyGov website.

https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests


26


Now, let’s see what score this text achieves when we paste it into Word and select Tools > Spelling and grammar. After the spelling and grammar check, Word gives us a little overlay of stats, like so:

As you can see, the text has a Grade level of 9.1, which means that the average person would need to have reached 9th grade to understand it. Interestingly, the Reading Ease score is 51.7, which according to Wikipedia, puts it in the 10th-12th grade category, described as “Fairly difficult to read”. Either way, most house digital writing style guides, and most digital writing leaders, advocate that digital text should sit somewhere around Grade 7. You may think that sounds low, but as this article points out, there is a veritable alphabet of accessibility issues that we all must deal with in everyday life. The reality is that the lower the reading level is, the easier text is to digest for every person striving to digest it. So let’s come back to this MyGov text. How can we reduce its reading level? As I mentioned, that’s the great thing about this reading level tests: they actually help you become a better writer. Once you have a score, you can look for ways to shorten your sentences, which generally entails using simpler grammar, and reducing the syllable count in words, which usually results in our using simpler, more common words. Let’s see how that works with our sample text. I’m going to tweak this on the basis that we have to refer to a “registered tax agent” as exactly that. I’ve assumed we have to call “MyGov Update your Details” that, too. Here’s a start: Change your contact details for other myGov services at myGov Update your Details. Change your contact details for the security codes MyGov sends when you log in, and for myGov notifications, in your Settings.

https://the-pastry-box-project.net/anne-gibson/2014-July-31

27


Warning Are these details for your registered tax agent? Consider contacting your agent before you change this information. Please fill in all fields marked with a *. Readability grade level? 7.5. You can see here that I’ve reduced repetition and made the text read a little more naturally, more like the way a person might say it. I’ve also made things a bit simpler — for example, replacing “mandatory” with a plain-English request that, I hope, would have the same effect. But what if we had free rein to change this text? Let’s see. Change your contact details for other myGov services. Change your contact details for the security codes MyGov sends when you log in, and for myGov notifications. Warning Are these details for your tax agent? You might like to contact them before you change this information. Please fill in all fields marked with a *. The readability grade level here is 5.6! As you can see, reading level scores make us question every word we use. Even if you’re not a writer, that’s a valuable thing to do — but a thing you might overlook in the rough and tumble of agile development cycles, signoffs, and testing. Reading level is a good way to focus on what needs changing, and it gives you a clear indication of how your changes are helping (or hindering) the pursuit of plain, easily understandable language. And in that way, it can actually improve your writing over time. TIP: Write text out of context The next time you need to write some microcopy for a new or updated page or screen or bit in your product, you’ll probably opt to write onto a wireframe. Many would write onto a wireframe on our monitors — that is, not even print the thing out and look at a hard copy. Why would you? Well, here’s a great visualisation of the terms and conditions of different digital products. It’s pretty ugly. It reminds me that back in the day, one of the shining lights in the then emerging

https://twitter.com/hailmika/status/992391607302451200

https://twitter.com/hailmika/status/992391607302451200

28


field of UX writing — it might have been Jessica Collier — advocated writing interface text out of the interface, and copying any existing text in that interface out into a Word or text document first. This lets you create a little conversational ticker tape, where words butt up against one another on equal footing, without formatting or positioning to help us understand their meaning. This way you can see exactly how much you’re saying — and how coherent it is, or isn’t — before you begin to add anything to it. That includes formatting, styling, whitespace, and so on. The image below shows what (roughly) appears above the fold on page load on my little laptop screen for two websites you may know: Airbnb on the left, and the hotel homepage of wotif.com the right.

You might say these sites no longer compete, but I, for one, switched from booking places on wotif to booking places on Airbnb once Airbnb got its grip on the world, so it’s at least interesting to compare the two. For the record, Airbnb has 34 words here; wotif has 116, more than three times as many. One thing that’s really, really great about taking the words out of the page context is that you can instantly see where you have conflicting messages. The wotif page offers me four calls to action: a Mates Rates subscription offer at page top and bottom, the search form, and the ad for a Hilton hotels deal. Airbnb, meanwhile, offers me one. Another great advantage of creating or adding to existing page text in this way is that you really get a sense of the tone of voice you’re using in a page of your

https://medium.com/@verbagetruck

https://www.airbnb.com.au/

https://www.wotif.com/Hotels

29


product, and where things are going awry. For example, Airbnb’s search advice reads: Try “Hiking in San Francisco” Wotif’s reads: Destination, hotel name, airport, train station, landmark, or address Which is more natural? You tell me. Wotif’s Mates Rates CTA includes two versions of the same word, but they mean different things. Strictly speaking, the invitation to save “an extra 10% or more on selected hotels” means it’s a limited pool of hotels that have already been chosen, where saving “an extra 10% or more off select hotels” means it’s a pool of special hotels. Two other minor points here: save $ on a price or $ off a price? You choose, but be consistent maybe? And “save an extra nn% off” is redundant; wotif’s adding words to the page here for nothing. As you can see, pulling text out of the page makes it very easy to look at what you’re saying, and how you’re saying it. It can help you sharpen your message, and make it more coherent. It can highlight areas where you need to support readers more, possibly by reducing verbiage or action options. And it can make it much easier to add new text in a way that will work — within this specific page, and for these particular users.

Understanding — and writing with — tone Tone involves two parties: the speaker and the listener. Tone is projected, but it's also interpreted on reception. In digital, people generally treat tone as the golden key to writing meaningful interface text. To be honest, I don’t agree with this position — I think simplicity and clarity matter much more — but once you have those, tone becomes critical, and it’s also a bit of a Pandora’s box. In a nutshell, tone of voice is how you express each informational (or other) message you need to communicate using text in your product. It follows, then, that tone of voice should directly reflect your brand in a way that responds to your audience. Let’s see how this works using two digital products: those period tracking apps Clue and Glow, which we saw earlier. Clue positions itself strongly as a “period and ovulation tracker” hinged on citizen science: “We use science and data to provide insights into female health.” Even its brand name speaks to this value proposition.

https://helloclue.com/

30


Glow, on the other hand, is pitched as an “ovulation calculator” and, looking at the app homepage, you get the sense that it’s much more pregnancy-focused: it’s “An App for Fertility & Beyond”. Again, the name of the app reflects this (pregnant women are always said to glow, right?). Just a glance at these two home pages tells us about the brands of each product. But how does that play out in the apps themselves? The “saving” messages that display when users add data to these products give us a pretty good insight. (As an aside, the messages that users see most often as they use your product — like "data saved" messages for data-logging apps — are a good place to start improving tone of voice.)

When you log information in Clue, it tells you, “Clue is getting smarter.” For a product championing science for the education and empowerment of women, the idea of getting smarter makes sense. Clue targets people who want to be smarter. The message that those people are in turn making the product (and their fertility and menstruation predictions) smarter is an excellent, thematically logical quid pro quo. Meanwhile, when you log information in Glow, it tells you that “magic and science” are working to save that data. Looking into the Glow forums, I see many would-be mums wishing each other “baby dust” so the mention of “magic” here seems spot-on for the target

https://glowing.com/glow

31


userbase. It reflects users’ obvious sense of wonder at the “miracle” of reproduction, and, too, the apparent unpredictability of pregnancy. The informational feedback these apps provide in these screens is: we are saving your inputs. But clearly, the words they use to express this messaging make an enormous difference to how the user feels about the product and, possibly, their data being stored or used by it. If you think your in-product text could have a stronger tone of voice, try this approach next time you’re writing some humdrum, everyday microcopy:

1. Revisit your brand’s positioning and audience.

2. Write the information you need to communicate in its simplest form (e.g. in the example above, it’d be “saving…”).

3. Revise that message using themes and words that embody your brand’s attributes.

Step 3 could take you forever, so perhaps aim for three different versions of the message, then run them past a colleague or peer (or two!) to see if what they believe will work best for your audience agrees with your own ideas. Remember to keep your text short and at a low reading level (grade 7 or below). And of course, if you can, test the text with your users.

Writing conversational interfaces Three years ago, few people knew what conversational UIs were. Today, it’s the phrase on everyone’s lips. While there may be comparatively few experiences that actually fit the bill right now, we’re moving ever closer to a conversational digital world. Conversational UX writing has some basic characteristics. It tends to use contractions, personal pronouns, and natural-sounding language — although, depending on your audience, you might want to dial down the idioms in favour of plain-English natural language. So let’s take a piece of text that isn’t conversational, and make it more conversational. Here’s some from a local council website: Council’s Strategic Planning team provides an integrated planning response to meet the challenges and needs of our community. —Reading level grade 12.0. Here’s my attempt at a more conversational rewrite:


https://www.moorabool.vic.gov.au/residents/building-and-planning/strategic-planning

32


Our job is to meet the needs of our growing community today, and to prepare our shire to thrive in the future. —Reading level grade 8.5. As you can see, it’s more natural. Human beings can probably more easily make sense of the words. But conversational tone isn’t enough on its own. Why not? Because UX writing isn’t just about tone. It’s about concept, logic, messaging and execution. It’s not just what you say, it’s how you say it, and how you say it isn’t just about the words you use. Think about it: different people you know would tell the same story differently. Sure, they’d use different words, but they might also tell the parts of story in a different sequence, or emphasise different points, and each would definitely express the story in their own unique way. Their unique telling of that story would reflect them, and it would also reflect their perceptions of you. A conversation isn’t just a conversation; it’s an expression of our personality and its purpose is to connect us with our conversation partner. Connect us how? I’d say emotionally, most of the time. A conversation comes from a person, and I believe your brand needs to have a personality if your conversation is to ring true; to remain consistent over myriad pages, interactions, and days/months/years; and to connect emotionally with countless users. Once you’ve nailed down your brand personality, making tone shifts for different situations (from marketing to product help to errors to crisis communications) is much easier, because you know who’s talking and what they’re like. You’re not writing UX text any more, or microcopy; you’re writing dialogue for your brand and product. Moreover, you’re creating a dialogue that users can engage with and contribute to, both mentally and practically (and of course, underneath it all, emotionally), themselves. But there are other considerations involved in creating that dialogue. One critical aspect is, of course, a global audience. This is crucial to a key element of a conversational UI, which is plain English. But before we get to that, let’s look at the problems everyday English can pose for those who don’t have English as a first language. The screenshots below show how character counts change in my phone's alarm app for different European languages. We always hear that German expands character count significantly, so it was interesting to me that the US Spanish version of this screen had the longest character count of the languages I looked at.

33


The other thing that language study will perhaps more subtly indicate is cultural differences in the way words and phrases are used in different languages. I don’t speak German, but I can’t help but wonder if the settings titles in the German version of this screen are initial-capped for a reason. Even if this is an anomaly not set in the ASUS style guide, it could reflect some intrinsic expectation or understanding on the part of the app's German translator. "So what?" you might think. "The product I work on isn’t offered in a language other than English." Well, even if that’s true, your app might expect to have a multicultural audience, including users whose first language is not English. And the fact is that English has some weird anomalies, and tech product people have normalised their use. The result is that the swift comprehension you were hoping for when you wrote those labels can take some serious brain power. Here’s an example.

It’s a pretty simple, very concise process description — but one that might pose problems for non-native speakers using Netregistry. Unfortunately, ing-verbs in English can be one of two things: continuous verbs (verbs for actions that have started but haven’t finished) and gerunds (ing-verbs acting as nouns), as is the case in the label Hosting & Extras. That’s before we consider that an ampersand may baffle a non-native English speaker.

http://www.netregistry.com.au/‎

34


But there’s another problem: Order Complete. The word “order” acts as both a verb and a noun in English. The word “complete” works as both a verb and an adjective. Which role is each word taking here? It’s reasonably easy for a native-speaker to decipher that in this case, Order is a noun (though it would be easier if all the other labels comprised only nouns). But for a non-native speaker, working this out might cause serious brain strain. The question is, do you need to know every nuance of English grammar in order to avoid this confusion in your interface text? No, thank goodness. I tend to think of a first language as being a bit like white privilege, if you have that: you can be as conscious as you like about its peculiarities and the way it impacts other people who don’t have it, but regardless, sooner or later you’ll act unconsciously on it, with bewildering or perhaps offensive consequences, depending on what exactly you do. What we need are some nice, solid rules to go by, and thankfully IBM has written just such a list. You’ll probably need university-level English to understand it, but if you have that, you’re set. This list is an excellent starting point for improving English-language interface text to make it more accessible to non-native speakers. And beyond that, you’ll want to focus on writing plain English. If we updated those Netregistry step names to plain English, they might read like this: Choose a domain > Choose extras > Pay > See order summary Remember also that a key tenet of conversational interface text (and written dialogue, and voice scripts) is: Don’t write what you wouldn’t say. Have you ever actually said “access” as a verb outside the context of the web? You might have used it as a noun in conversation: Does the building have wheelchair access? for example. But I would literally never ask, Can a person in a wheelchair access the building? I'm sure I've asked, Can you access your account? But the context is digital. I can’t access this jar. Can you unscrew the lid for me? No. So perhaps we should expand that key tenet to read: Don’t write what a “normal person” wouldn’t say in the real world.

Using accessible words Word choice matters. UX writing is all about word choice, as a critical element of the basis of linguistic expression, and you’re working on it every day.

https://www-01.ibm.com/software/globalization/guidelines/guideb.html

https://www-01.ibm.com/software/globalization/guidelines/guideb.html

35


The role of plain English in products is undeniable, yet once we’re up to our elbows in product design it can be nearly impossible to get the distance we need to think about it in a plain-brain, plain-language way. I saw an example of this this week. A friend sent me pages from their product, which offers users a paid upgrade to a more detailed profile that really gives them the functionality to demonstrate their capabilities in their field. A similar example would be a paid profile upgrade for independent professionals (that is, people who aren’t and don’t want full-time permanent employment, but are small business owners and freelancers) on LinkedIn. The pages outside and inside the product contained messaging about “your personal brand.” While the term “personal brand” apparently dates back to the 1930s it’s only really gripped the (digitally connected) planet since the internet became A Thing. Does it exist in some form in other languages? I don’t know. But I’m skeptical. My research has recently got me thinking that every word or phrase has what we might call an “accessibility factor”. That factor takes into account two things: the level of English you have to be to understand the word, and the cultural knowledge you must have to make sense of it in context. As we’ll see a little later, simple Australian phrases like, “How’s it going?” may be accessible on a word-by-word basis, yet many native English speakers from countries like the USA simply do not understand them. This is what I mean by “cultural knowledge”. Here I’ve illustrated the point, poorly but, I hope, adequately.

The words I’ve included here, other than the infamous “How’s it going?”, are explained below. But the idea is, the further you get from the 0-point on the graph, the lower my proposed accessibility factor of that word. A word’s positioning reflects (my best guess at its) its cultural or linguistic accessibility.

https://medium.com/@georginalaidlaw/the-real-role-of-plain-english-in-products-3e5d5af9e36a

https://en.wikipedia.org/wiki/Personal_branding

https://en.wikipedia.org/wiki/Personal_branding

36


Now, the target audience for my friend’s profile upgrade is adults of all ages, and their line of work relies heavily on relationship building. So, as I reviewed the product, I started thinking about the audience’s own potential audiences, for their paid profiles. Instead of focusing on what the product gave its audience (features), I thought about what it made possible between that audience and their audiences. Those things were not personal branding. They were things like:

relationships reputation confidence the right expectations.

A not-small minority of the target audience for this product are, I’d estimate, 50+ and are not heavily internet-focused. They’re people-focused. So these more “generic”, less “trendy” terms seem to make more sense for this product. More interestingly though, if we start talking about relationship building rather than personal-brand building, we actually end up repositioning the product. That is, by changing the vocabulary, we move the product presentation from being about a digital personal branding tool. Instead, we make it about a smart way to start building strong relationships with the right people, and developing their confidence in you before you’ve even spoken with them. For a highly competitive marketplace (in which my friend’s product operates) this probably isn’t a bad position to take. What does it mean for interface text? Let’s see some before-and-after examples. The “before” text is on the left.

37


These are just quick ideas, but you can see how thinking in terms of relationships and reputation can influence the style of language we use to describe the different features in a product. In particular, we’ve changed the report focus. Originally it focused on pieces of the interface. Now it’s talking about people. And that’s what prospective clients are, right? So whenever you’re faced with audience- or context-specific terminology, think about more general terms that do the same job, but perhaps carry more meaning, or associations that can benefit the product. Consider, too, the idea that perhaps every word has its own “accessibility factor”, and we need to keep that in mind as we develop terminology for interface text and product lexicons. Also, understand that the words we choose can influence the positioning of our product or brand. Lastly, document the words you do use so that everyone knows they’re important to the product and brand. Sometimes, plain English text can look so natural that people don’t realise how carefully chosen and sharply honed it actually is. Don’t let other writers, designers or product people undo your good work later: document what you do in your product lexicon as you go.

Respectful writing Respectful interface text is a topic that deserves genuine consideration. Every one of us is different, after all, and I may not even notice something that is deeply offensive to you. As an example, consider this tweet, in which designer, writer and illustrator Kat asks Skype what’s up with its gender selection options. Kat’s offended by the choices offered there, because they don’t identify as either of the two genders in this list. I, on the other hand, merely roll my eyes at how bizarre it seems to ask people to identify their genders, and then only give them two options in 2018. Kat and I are different people, with different responses. In UX writing — a form of mass communication with broad audiences — respect is key. Apple Dictionary describes respect as “due regard for the feelings, wishes, or rights of others”. Great. But … how do we give that due regard? What kind of regard even is due? The answer is to get to know your audience beyond their interactions with your product. Understand who they are in a more general sense, and what their sensitivities are in the real world.

https://twitter.com/butwhoiskat/status/1003507391424417792

38


As you do this, you’ll likely find that, alas, each member of your tightly-defined target audience is, in fact, different. At first this doesn’t seem very helpful. I can’t tailor my UX writing to every single person who might use a product. But what this does is allow us to identify potentially risky communications (and interactions) that we might want to reconsider. Like asking for someone’s gender, for example. If you determine that that’s necessary or useful, what about giving them more than two options? Of course, the other side to this coin is that it’s dangerous to think that we know what’s what in terms of being respectful to other people. To find out more about this I spoke to Tanya McKenzie, Health Literacy Manager at the Peter MacCallum Cancer Center in Melbourne, for the newsletter. You can — and should — read the full interview here. Tanya kindly listed a number of techniques that she applies in her writing to build and show respect for users, so do take a look. Ultimately, respect starts with becoming aware of, and understanding, difference. So, if you’re looking to show more respect to your product’s users, a first step might be to stop looking only for “average” users as test subjects, and start actively searching for and talking with people who represent minorities in your user group, too.

Writing for other languages From what I’ve been seeing through my work with commercial apps, translation isn’t considered until a digital product’s reasonably established. At that point, the business usually looks for a translation service online, sends their text away, and gets a translation back. I’ve had both designers and product managers tell me things like, “I don’t think anyone really confirms the quality of the translations. We just hope they’re okay. But we don’t have huge markets in those regions yet, so…” Let’s face it: translation is tough. Where should you even begin? The key points to understand is that translation is not a binary, yes-or-no, done-or-not done proposition. Like all writing, there are no objectively “right” answers in translation, though there are definitely wrong ones. Translation difficulties are likely to become the norm as we build ever more conversational interfaces with a strong tone of voice. The more natural your interface sounds in English, the less likely it is to be directly translatable into another language. If this all sounds like a bit of a nightmare — or a challenge to which you want to rise — then, great news. I spoke with Sonia Sánchez Moreno, Director of Sylaba Translations to find out how you can home in on a good translation for your

https://www.petermac.org/

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-23-respect

http://sylaba.com.au/

http://sylaba.com.au/

39


product. And how you can write interface text that supports that goal. See the interview for her detailed advice.

Colloquial and idiomatic language One thing I’ve noticed working with startups in Melbourne, in particular, is that they prize their Australian roots, and are keen to maintain a laid-back Aussie voice in their digital products. I expect it's probably true for Kiwis, Brits, and Americans, too: there are many digital brands out there that want to embody the best parts of their local culture. It may be similar in other cultures that don’t have English as their national language. For Australia, it’s true that Australians appreciate an Australian tone. It’s also true that this is very difficult to actually achieve. But one brand that’s doing it pretty well is NAB.

Giving something a go is particularly Australian. A go is an attempt (as in “fair go”) and no English speakers but Aussies use go in this way. North Americans don’t even understand the question “How’s it going?” at first, um, go. Therein lies the hint of the bigger problem with being — and sounding like — an Aussie. People may not understand you. Which people?

People from English-speaking countries that are not Australia. People from countries where English is not the first language, who now

live in an English-speaking country (like Australia). People who don’t speak English as a first language, nor live in an English-

speaking country, but do use your product.

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-16-crossing-the-cultural-divide

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-16-crossing-the-cultural-divide

40


It’s easy to think of globalised audiences as being people who look different from you, speak English with an intriguing accent, and live in exotic locations. But the less glamorous reality is that even the little old NAB app is being used by non-native English speakers from other places who have moved to Australia and now have to contend not just with Vegemite and racism, but also, “We’ve lost you”, and “give it another go.” Recently I was working for a global business whose Australian-based HQ had recruited employees from all over the world. A couple of product managers from the US mentioned that they didn’t even know if other Americans would understand some of the copy that was being written (in many cases, by non-Americans who had lived and worked in the States for a period of time). And as for those who weren't native speakers ... well, who knew? That said, my adventures in English teaching constantly remind me how valuable dialectical phrases like “give it a go” are in creating emotional connection between people who obviously differ. When we hear someone talk like we do, we may not be able to help presuming a raft of other commonalities between us. In short, idioms make friends. In digital products, that's definitely desirable. Indeed, when I saw that error message in the NAB app, my heart was warmed — a valuable feeling at a time when I was facing a show-stopping problem. However, there are a few things to consider if you want to apply an Australian tone or flavour to your product. 1. Is your audience Australian-only? If you think you may ever want to build your userbase in other countries — even just English-speaking ones — having Australianisms in your interface text is A Bad Idea. When I worked on an Australian b2b product with a “friendly” Australian tone that didn’t even involve colloquial language, our Japanese translator (and the others, but to a lesser extent) was eternally rewriting text to make it more formal and respectful for the Japanese market. Is that how your business wants to spend its money? If not, work to avoid localised English in your microcopy. 2. Is your primary audience native-speaking Australians? If the answer to 1. is yes, and you answer yes to this second question too, then perhaps, like NAB, you can use a hint of Australian English in your microcopy. 3. Where and how should you use Australian English? This is something you need to pay attention to if you’re going Aussie. Yes, you want the product to connect with Australian-speakers. But you don’t want to confuse or discourage secondary audiences who may not speak Australian. If I were you, I’d:

41


Use Australian language for non-essential tasks. Don’t make a nuanced understanding of obscure words necessary to get things done with your product. Even something as seemingly innocuous as “Give us a tick” (translation: please wait a moment) makes no sense to people who don’t speak Australian.

Keep the Australianisms to secondary messages, as NAB has done here. I

recently saw a display-on-page-load user notification for a US online store that read “Your cart’s empty. Let’s fill up this bad boy with today’s specials.” It was a cute, American-English explanation supporting a plain-English primary message.

Keep your primary messaging comprehensible by using plain English. An

example is that big Go to settings button in the NAB interface. How will you know if you’re getting it right? Test your copy with people who aren’t native English speakers, and English speakers who weren’t raised in Australia. I promise you, many of the phrases you use from your native English dialect will seem so natural that you won’t even realise they’re a problem. Testing is key.

In summary… Language matters. The first tenet of writing good interface text may be don’t write what you wouldn’t say, but as we’ve seen in this section, we need to think about a range of things as we construct our text. Before we begin to write, we need to consider the broader personal and cultural sensitivities of your user base, to make sure we keep the risk of offense to an absolute minimum. We also need to consider the task of translation, if that’s on the agenda for your product, and make sure our English is plain enough to make the task cost-effective — and to do that, you’ll likely need to involve translators from the start. Ultimately, we want to aim for conversational interfaces that communicate in the tone of our brand, using words that are effortlessly accessible by as many users as possible. Keep in mind, though, that plain language can easily segue into idiomatic and colloquial expressions, so we want to keep close watch on the phrases we use. And if it all seems too much? Start using a reading level calculator to help you improve the readability of everything you write, from the ground up. Next up, in our final chapter, we’ll see how the concepts we’ve discussed so far play out together in real-world applications. See you there!

42


4. APPLICATIONS Before we wrap up, I wanted to show you a few bigger-picture applications of the techniques we’ve discussed so far, so we can really see how this stuff plays out in practice. Here we’ll look at the things we need to consider when we combine UI text with imagery. We’ll review onboarding, product help, and system or transactional emails that are sparked by the user’s interaction with the product. And we’ll take a close look at lists, which play an important role in communicating the structure of information in an interface. Perhaps as you go through this section, you’ll be able to think about some examples from your own product, and whether they may need improvement. That’s my goal, anyway.

Combining text and imagery We’ve talked about The Process, and we’ve seen how design principles can be translated into word design principles. But it would be a mistake to think that the words exist in their own right, or in a vacuum. The reality is that your words will often need to work alongside imagery. And that can be challenging. So let’s take a quick look at the kinds of things that – even armed with design principles and a solid text development process – you need to consider when you mix words and imagery. Here’s an error page from YouTube for your consideration:

Cute, huh? Who doesn’t love a primate with headwear? At first glance, this 404 page meets the criteria for a good error page:

43


1. It prioritizes the message, not the error number. Normal humans don’t know error numbers. If you do, and you want to know what error type this is, you can see the error number in the page title. 2. It provides a clear path to a solution. The information is clear and that search box is pretty hard to miss. 3. It’s got “personality”. The purple chimp does give us a giggle — and gives the page some personality.

Cool bananas, right? Not so fast, Bobo! As your consulting doctor, I have some cap-q Questions... 1. Whose personality is it? Google's error and empty state messages (e.g. in Inbox) take a similar visual style to the image used here. Design-wise, they're consistent. But in terms of characters, they’re not. Who’s the chimp? What’s his deal? He feels a bit like a hasty, half-baked gap-filler — like the designer was at a loss and as a last-ditch effort to make the boring engaging, found themselves crying (at least internally) bring out the chiiiiiiimp! Harsh? Inevitably. But I’m wary of using one-off visual devices simply to charm, since they take a major role in your narrative and reflect so heavily on your brand. A mascot is a mascot. A chimp with a magnifying glass is narrative fluff (sorry, little fella). 2. Does the text reflect that personality? No! What chimp uses four-syllable words like “available”? No chimp I ever met.* Also, “This page isn’t available” is almost a contradiction in terms — like saying “these keys aren’t here”. True, “this” page is indicated in the URL, but if the rule for writing in-product text is “don’t write what you wouldn’t say”, this text breaks it. If you’re going to go to the trouble of designing a dapper Pan troglodytes, you might as well make the text that goes with him equally street. Like how? Here are some ideas.

We can’t find that page, sorry. Search for something else. Sorry, that page isn’t here. Try another search. Oops, that page is missing. Search again.

I’m no fan of “Oops” (nor "Whoops" as the Brits spell it), but I’m forced to concede that it does seem like something a cap-wearing chimpanzee might say if it spoke English. The actual page text has a Flesch Kincaid readability grade level of 7.7 (which means people who studied to year 7 in highschool can understand it easily). The readability scores of the options I’ve given here range from grades 6.0 to 5.1. And


44


as we’ve seen, the lower your grade-level score, the easier your message is to grasp. Remember: everything you put on the page matters. Everything. If you're using visual devices, don't just design "cute". Design something that contributes to your brand story, and be as conscious about choosing words that agree with it in tone as well as functional messaging.

Onboarding What is onboarding? Recently, while speaking with a friend about writing for onboarding processes, I realised that it’s a pretty broad term. Some people call a few intro screens that highlight worthy features of their app — that is, features that the user needs to know to get essential value from the app — “onboarding”. Other people describe a process that a user must necessarily go through to use a product (e.g. connection with external accounts) as “onboarding”. So which is it? I guess it’s both, right? Perhaps we can define onboarding as any steps we take the user through the first time they use our product. For that reason it’s important to remember that the user probably doesn’t really want to go through the process — it’s more likely to be something they feel they have to do. Indeed, many apps make us do their feature-tour onboarding, and that can be boring, so maybe we should consider making a non-essential onboarding flow optional. In a previous life I wrote a few feature tours/in-product help tours for software, and what I learned was this: three to five steps was the ideal length of those tours. I know this advice should be accompanied by all kinds of audience- and product-related caveats, but this experience (and my experience as a user of digital products, and my experience watching others use digital products) has seared this number into my brain with a white-hot iron. So much so that I aim for the lower end of that spectrum wherever possible. Does it always work? No. The last onboarding flow I worked on had six info screens, and was bookended by welcome and thankyou messages. That’s eight clicks, total. But if we’re aiming for three to five clicks/chunks of information (because of course, we’re allocating one click to each piece of information or “step”), where do we begin? With user pain points — specifically, the most painful pain points your product addresses. I would list those points in order of painfulness, with the most painful coming first. Then I would shape my onboarding around those.

45


If the onboarding process must necessarily involver certain “setup” steps — like adding a credit card, or linking some other account — those will likely need to be included alongside (or instead of) any broader pain points you might like to include. In that case, I’d be tempted to separate out the essential onboarding from the nonessential, and, again, make the latter into an optional feature tour. The important thing here is to think in terms of pain points or problems that your product solves, rather than features and functionality. That can be difficult if you’ve developed said features and functionality, but for onboarding, we want to put ourselves in the users’ shoes entirely. And that means: no agenda. A while ago I mentioned some work I’d done on a non-optional onboarding process created by a UX team where step two basically repeated step one. When I asked the lead UXer why that was the case, she said she really wanted to make it clear that you needed access to this external service in order to use her company’s product. That’s an example of an agenda. You can imagine the implications: a longer onboarding process, frustration for people trying to get through it as quickly as possible, potential confusion (“Didn’t they just say this?”), and so on. I think as a rule we want to avoid preempting onboarding steps with other steps. Three to five, remember? Now we have our pain points, and we have our steps. Note those down as messaging, I say. Don’t write them yet. Messaging will help you reveal any kinks in your step logic, and anyway, there are a few other things to consider before we write: 1. Will you have a “welcome” message and a “contact us with questions”

message to begin and end your onboarding process? Unsurprisingly, my vote is for no — where possible I’d try to include those messages on pages that actually do something meaningful for the user. Cut the fluff — and the clicks.

2. Will you include link/s to more detailed information for those who need it? That may be a downloadable setup guide; it may be an online help library — whatever. Consider whether you will include links, and if so, how you’ll do that to avoid confusing or losing users during the onboarding process.

3. Are you respecting your users, by revealing only what they need to

know as they need to know it? As we saw earlier, respect is critical in helping people through challenges. The point I made about help links above is a good example. You’ll want to make sure any help you link to is developed specifically for users in that process, so you can serve them the information they need to know in bite-sized chunks, rather than scrolling through reams of more general help to find the tiny section they may need.

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-13-just-say-what-you-mean

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-13-just-say-what-you-mean

https://tinyletter.com/MelbourneWordSchool/letters/word-design-doctor-23-respect

46


4. How does the visual execution support these objectives? Words and visuals must work together, after all — at least for those who have vision. The issues here are beyond the scope of this ebook; visual designers will be able to shed more light here than I ever could.

Onboarding isn’t simple. The key is to put yourself in the position of a user, rather than someone who wants to show off their shiny new product. The natural results of that approach will be:

a short sequence arranged in priority order (or logical flow) demonstrating the product’s solutions to key user pain points.

There’s no room for agenda, nor fanxing (or fangirling, fanboying, or fantheying). Write it in the language of users, and keep that language level as low as possible. Onboarding is not the time to introduce product-specific vocabulary unless it’s explained in full and in context — which is likely a step of its own in your flow.

Lists Remember that time the Hawaiian missile defence staff erroneously issues a missile alert and Hawaii went into lockdown? It as right before Kilauea erupted, melting houses and manufacturing new land. Anyway, this experience taught us a few things about lists and real-life, user-populated interfaces simultanouesly. Good times, my friends. Take a look at the missile-alert-launching interface. Now, let’s see what we learned. Consider visual hierarchy There’s no visual hierarchy in that list. It’s a bunch of links on a page. When we can, we need to give list items a visual hierarchy rather than assuming people will be able to infer that. We create hierarchy by:

grouping like or related items using fonts and spacing judiciously enforcing hierarchy into the actual text of list items (through

numbering/ordering list items, structuring the text a certain way and/or for scannability, and so on).

Take extra care with user-generated lists Some of the information I saw about this page indicated that this was a list of user-generated alert templates. If that was the case, then the link text itself may be largely beyond the control of the system's designers. Yes, they could force people to specify different information in different fields and display that information in sequence in or near each link, but we’ve all seen

https://twitter.com/CivilBeat/status/953127542050795520

47


cases where this degree of prescription is counter-productive, or so cumbersome that it’s not followed (right? Well, I have — often I’ve been the one not following it, for perfectly “good” reasons seemingly not anticipated by the designers). Bottom line: user-generated content is only as good as the training and commitment of the people using your CMS. If you're worried about that, consider adding confirmation steps to important selection processes, or have people review what they're approving before you accept their click as Gospel. Display meaningful text Why am I only getting to meaningful text now? Because visual hierarchy is the first cue users are going to use to make sense of a list. Once they believe they understand the (literal) shape of things, then they’re going to read the contents of a sub-list. And I understand this list was made by users, which gives us a separate layer of complexity to handle before we even get to the words those people are writing. But here we finally are. So what about meaningful text? Obviously the average Joelene takes one glance at that link list and can make no sense of it. But again, let’s put down our outrage and assume, for the sake of argument, that training makes the terms in these list items sensible for those using them. If all the terms followed the same structure within each list item, the user may not have made the wrong choice here. Indeed, taken on their own, the PACOM (CDW) - STATE ONLY and DRILL - PACOM (CDW) - STATE ONLY links are clearly different. These list items take the same structure, which is always advisable when the items are logical partners, since it makes the comparison easier. The fact that the DRILL link says DRILL at least hints that the link without this term might be a real alert (although I’d personally put DRILL at the end, so the link text was initially identical at a scanning level. My sense is that this makes the differentiation between options much clearer). Does any of the letters in the link stand for “Alert”? I can’t tell you — that’s where domain knowledge, jargon, and training come in. What we can say is this is a list of real alerts and test alerts, and if the links necessarily included that information in the same place, using the same language each time, this list would be easier to use. Adding a dropdown for Test or Alert or whatever, and perhaps a mandatory short description field to each one in the CMS, and then displaying that extra information within or alongside each item in the list might be helpful. I know — I said that kind of thing might be too cumbersome a moment ago. Well in some cases, maybe it won't! In any case, ordering list items alphabetically is usually a good way to go, because then, like items can appear side by side, which makes comparison (and hopefully correct selection) easier. Giving users the ability to order and group items like this on the page themselves is probably another worthwhile option — so long as whoever has that responsibility takes it seriously, and those using the list understand their methodology.

48


In-product help The days of the FAQ page are largely over. Now, brands feel their design is so good, and their audience sufficiently experienced with technology, that they don’t need to provide off-product help for users. We can do it all in-product, with good design and some well-chosen words. This is a bigger challenge for the UX writer than the days where we could leave the words out of it, knowing we could link off to more information on a help site. Enter: the ever-useful tooltip. Meetup uses one on its meetup page — and in fact links from it to more information on a help site.

The text reads: This group’s content, including its members and event details, are visible to the public. As it happens, I’ve just been working on a plain-English interface with a number of plain-English tooltips, and we can see that this tooltip doesn’t use plain English. Word tells me its reading level is 9.2. As well as jettisoning of the passive voice, the plural agreement error, and that subordinate clause between the commas, here’s a list of all the words in this text that I’d try to avoid as “jargon”:

content members event details visible public.

Wait, but what? It’s called a “public group”! Yes it is. As the tooltip links through to more information, we might be fine to use the word “public” in the tooltip. But what if we didn’t want to have a help site? How can we make this text clearer? Let’s see. Everyone who comes to this site can see everything about who’s in this group and its meetups. Reading level? 7.6. But what if we wanted to remove the word “meetups” on the

https://www.meetup.com/

https://help.meetup.com/hc/en-us/articles/360002921751-Meetup-Group-Content-Visibility-Settings

49


basis that this brand-word is probably fairly difficult to translate? Everyone who comes to this site can see who’s in this group, when they meet, and why. The reading level of this text is 4.2, my friends. Four point two! If I were Meetup, I’d opt for this version, and open some champagne. If, as a user, I read that definition, I don't think I'd bother about clicking through to more information: I get it. So, depending on the audience, this may well be the kind of text we might aim for if we don’t want to have a help site. Remember, though, that if you’re trying to educate your users about product vocabulary (like “public group”) you want to use that vocab consistently throughout your product. If you have a help site, that’s even easier, because you can use more words to contextualise product vocab there. But if you’re including tooltips and hints as a means to avoid having a help site for your product, you don’t have such a luxury. In that case, my gut instinct (and recent experience) says to avoid product vocab in tooltip definitions of terms and concepts in your product. To do that, you need to use the plainest English possible. And to do that, you need to question every single word you’re using, and find a way to say it more simply.

Product email We can write a product email using the same process I described for microcopy, with a couple of tweaks. Firstly, understand the context in which the user is getting the email, and what the point of the email is — what it’s trying to get them to do, if anything. Then, understand who you’re emailing. Next, unearth the component specs. At a minimum, you’ll need to write:

a from address a subject line the email salutation, body and signoff any link required.

Now, write messaging of no more than, say, two or three short sentences. Don’t try to make it sound like anything other than messaging: the crux of what you need to communicate. Finally, refine that text carefully. Keep in mind that your email text needs to be true to your brand and your users. It also needs to:

50


be scannable aim for a reading level of around grade 7 be easily comprehensible by people who don’t speak English (or the

language you’re using) as their first language probably link to support information or a help contact.

Product emails aren’t afterthoughts: they’re an especially challenging aspect of your brand experience that takes place outside your product environment. So, don’t sell your brand or your users short by falling back on solutions that are pre-packaged, or just plain bad.

In summary… In this chapter, we’ve looked at some applications of microcopy in practice, from errors and onboarding flows, to lists, help, and product emails. The important thing to remember with applications, as with all microcopy and writing more generally, is that there is no “right” answer. But there are good and better answers, as well as objectively terrible, unhelpful, or confusing ones. Our job as creators of microcopy is to study, practice, and help those around us, from product owners to marketers to designers, understand what makes good product microcopy. This isn’t just about making “nice” interfaces or creating moments of delight. It’s about making the web more usable, useful, and inclusive. Words matter. What you say in your interfaces matters. So take care, and write well.

Starting Points for Better UX Writing - Melbourne Word School · 3. Language 4. Applications. The...

Documents

Transcript of Starting Points for Better UX Writing - Melbourne Word School · 3. Language 4. Applications. The...