Starting Points For Better UX Writing: by Georgina Laidlaw

Starting Points for Better UX Writing
By Georgina Laidlaw
1
© Georgina Laidlaw 2018
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
2
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
3
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?
4
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.
5
 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.
6
7
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.
8
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.
9
10
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:
11
 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.
12
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
13
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!
14
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
15
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
16
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.
17
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.
18
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,
19
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.
20
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
21
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
22
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
23
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.
24
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.
25
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.
26
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
27
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
28
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.
29
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
30
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:
31
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.
32
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.
33
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.
34
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.
35
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.
36
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.
37
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
38
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.
39
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:
40
 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!
41
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:
42
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
43
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.
44
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.
45
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
46
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.
47
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
48
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:
49
 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.
50

Starting Points For Better UX Writing: by Georgina Laidlaw

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Starting Points For Better UX Writing: by Georgina Laidlaw

Uploaded by

Copyright:

Available Formats

Starting Points for Better UX Writing

I’ve organised it into four sections:

Let’s get started.

Step 3: Component specs

This is not about linguistic expression; this is about a gut-reaction

The Process in action

Let’s imagine we work on the VicEmergency App. A colleague has come to us

Here it is: the VicEmergency app aims to keep Victorians apprised of

Are there any component specs?

To my mind, the difference between Warning advice and Community

The question is: what should our messaging be?

The layout over the page.

Why? Because visual/experience/interaction design naturally involves text. The

And the writing principles read:

Also, there’s a mix here of principles (general overarching guidelines about

 Universality: Speak to everyone.

Visual and tactile, Familiar

Styles are specific directions on using certain words or grammatical conventions

That is, words and grammar.

Look at those first two checkboxes. They read:

Who am I again? Me-me or you-me?

A personal pronoun is a pronoun that we use as a substitute for people's names:

What’s that? Did I just say “controversial”?!

So what’s the prescription for avoiding personal pronoun pain?

2. Don’t cross the streams.

Next up is passive voice. Or as I like to call it, Robot-speak.

Let’s look at Glow first.

We’ve updated your predictions.

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

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

Great! Nice! True! … in this case.

Woohoo! Job done!

Inconsistency draws our attention, and wastes our energy. Inconsistent

Capitals (or lowercase) shouldn’t be used alone in an effort to differentiate the

These are the kinds of capitalisation tribulations UX writers must necessarily

Don’t use capitals alone to differentiate the function of text in an interface.

We covered pronouns, the passive voice, punctuation and capitalization, all of

There are interesting times ahead. Let’s get into it.

Understanding Reading Level

As an example, let’s take some text from Australia’s MyGov website.

Please fill in all fields marked with a *.

Change your contact details for other myGov services.

Please fill in all fields marked with a *.

The readability grade level here is 5.6!

TIP: Write text out of context

Why would you?

Airbnb, meanwhile, offers me one.

For example, Airbnb’s search advice reads:

Which is more natural? You tell me.

Understanding — and writing with — tone

Clue positions itself strongly as a “period and ovulation tracker” hinged on

For a product championing science for the education and empowerment of

1. Revisit your brand’s positioning and audience.

2. Write the information you need to communicate in its simplest form

Writing conversational interfaces

Conversational UX writing has some basic characteristics. It tends to use

Council’s Strategic Planning team provides an integrated planning response to

Here’s my attempt at a more conversational rewrite:

A conversation isn’t just a conversation; it’s an expression of our personality and

Unfortunately, ing-verbs in English can be one of two things: continuous verbs