Microcopy writing guidelines

Microcopy is the small bits of text in user interfaces and apps. It’s what makes and helps users
do “stuff”. You encounter microcopy every time you use an app or the internet. When it’s doing
its job well, you don’t even notice it.
Examples of microcopy are error messages, field labels, ToolTips, and button text.
This booklet provides general guidelines for writing microcopy.
If you have any comments, examples, or ideas you’d like to share with me, drop me a line at
rakefet.zur@gmail.com .

What’s in this booklet

General guidelines before you start writing.................................................................................... 2
Voice and tone................................................................................................................................. 3
Know your audience ........................................................................................................................ 3
Error messages ................................................................................................................................ 4
Confirmation messages ................................................................................................................... 4
Buttons ............................................................................................................................................ 5
Empty states .................................................................................................................................... 6
Waiting times .................................................................................................................................. 6
Placeholders .................................................................................................................................... 7
Page not found (404 pages) ............................................................................................................ 7
Microcopy writing checklist............................................................................................................. 8
Useful resources .............................................................................................................................. 8

Microcopy writing guidelines rakefet.zur@gmail.com Page |1

General guidelines before you start writing
Speaking to people like human beings, rather than machines, creates an emotional connection
that results in a better experience with your product. Microcopy is our way of communicating
with the users in an app or website.
The right microcopy in the right place can help anticipate the users’ questions and alleviate their
anxieties, and communicate clearly what they stand to gain from taking action. For example,
people can be suspicious when a form asks them to provide personal information such as phone
numbers, email addresses or their date of birth. Microcopy can help lessen these doubts,
specifying what your phone number will (and won’t) be used for. Microcopy can reduce the
perceived cost or increase the perceived value and in that way improve the user’s response.
Quick writing rules:
 Never use a long word where a short one will do.
 If it’s possible to cut a word out, (almost) always cut it out.
 Never use the passive where you can use the active.
 Never use a foreign phrase, a scientific word, or a jargon word if you can think of an
everyday English equivalent.
 Person
 Address users as you, directly or indirectly.
 Use the second person (you, your) to tell users what to do. Often the second person is
implied.
Examples:
Choose the pictures you want to print.
Choose an account. (implied)
 Use the first person (I, me, my) to let users tell the program what to do.
For example: Print the photos on my camera.
 Use we instead of using the name of your application or company.
For example, use we recommend rather than it is recommended.
Or: we’re experiencing a problem on our end.
 Avoid using third-person references (the user) because they create a more formal, less
personal tone.
 Embed links in relevant, descriptive language.
 Use simple words.
(https://en.wikipedia.org/wiki/List_of_plain_English_words_and_phrases)

Microcopy writing guidelines rakefet.zur@gmail.com Page |2

Voice and tone
Voice is your company’s brand personality described in adjectives.
Tone is a subset of voice. Tone shades your voice based on the audience and context.
You can read NNGroup research:
 The Impact of Tone of Voice on Users' Brand Perception.
 The Four Dimensions of Tone of Voice
Examples of voice and tone guides:
 List of many voice and tone guide: http://voiceandtoneguides.webflow.io/
 MailChimp: http://voiceandtone.com/
 Shopify: https://polaris.shopify.com/content/voice-and-tone#navigation

Example of how to build a guide: https://gathercontent.com/blog/tone-of-voice-guide

List of adjectives for describing your product/brand: http://cfarman.com/blog/adjectives-for-
describing-your-brand/
To write a tone guide, for each type of message and text write:
 What’s the scenario – what just happened?
 How does the user feel right now?
 Give an example of how not to write.
 Give an example of how to write.
 Add tips.

Know your audience

Even professionals want clear, concise information devoid of unnecessary jargon or complex
terms. Remember that no one has ever complained that a text was too easy to understand.
However, your audience affects your word choice and how much and if you need to explain new
terms or which types of terms.
Consider your audience’s reading level, the concepts and vocabulary with which it is familiar,
and the questions it wants answered. Then write for that audience.
You can read a bit about how the audience affects your writing here:
https://www.nngroup.com/articles/plain-language-experts/

If you want to test your writing, you can use the websites below. Some of these tests even
suggest edits to make your writing more readable.
 Readability-Score.com
 Hemingway Editor
 The Writer’s Readability Checker

Microcopy writing guidelines rakefet.zur@gmail.com Page |3

Error messages
Error messages are the text we hope the user will never see. However, no system can work
without errors. It can be a user’s errors or a system fail. In both cases, it’s very important to
handle errors in a right way as they are crucial for a good user experience.
Good error messages:
 Increase speed of use
 Increase users subjective satisfaction
 Reduce repeat errors and complaints

Good error message should:

 Clearly indicate what went wrong - clear text message describing the error.
 Clearly define what the problem was, why it happened, and what to do about it.
 Be written in the user’s language (meaning, not like a programmer, unless your user is a
programmer).
 Be specific to the situation and not one error message for all validation states.
For example, if the email field is empty or if it is missing the @ sign, you can provide
different error messages.

 How to fix it - provide a solution.

 Provide a solution so that users can return and complete the process immediately or
know what to do next.
 If the problem can’t be solved at that moment, tell the user what can be done to help
them, and who they can turn to.
 If possible, guess the correct action and let users pick it form a list of fixes.

 Right placement.
A good error message is that one you can see exactly where it’s relevant. Avoid error
summaries, place error messages next to the UI elements they are related to.
 Aim for high information density — that means packing as much as you can into the
smallest number of words.

Confirmation messages
A Confirmation message is a message that users see when they are explicitly asked to proceed
with a task they initiated.
A good user interface does not require many clarifications.
Confirmation messages are only necessary when the action:
 Is risky. The user is about to take an action that has significant consequences that cannot be
easily undone.
 Can have unintended consequences. The action itself might not be risky, but there is a
significant side effect of the action that the user needs to be aware of.

Microcopy writing guidelines rakefet.zur@gmail.com Page |4

 Could have more than one outcome. There is more than one way to perform the action, so
the user needs to confirm the desired outcome. These are usually presented as a choice
dialog, but they have the effect of being a confirmation as well, particularly if the user
doesn’t desire any of the offered outcomes.
Don’t add lots of explanation in the confirmation message. The more you add, the less likely it is
to be read. (If you’re writing for mobile, you even have less space.)
Even if users don’t read the text, they’ll look at the buttons. So focus on the button text,
because you can use it to make the choice you’re offering clear. Make sure the user knows what
consequences of the choice are and reinforcing the choice in the button text.

Buttons
Buttons communicate the action that will occur when the user touches them. They are the point
when a decision becomes an action. Example actions are ‘Download’, ‘Open an account’,
‘Import documents’. The text on the button should begin with a verb. Otherwise, it’s not a call-
to-action, it’s just a button with some text on it. ‘More information’ for example, is not a call-to-
action button.
Think about what your users would say if you asked them what they were trying to do. Use
those words for the button.
Guidelines when writing buttons:
 Label the button with what is does
 Start with an imperative verb - Start labels with an imperative verb and clearly describe the
action that the button performs.
Exception: You can use the following standard labels without verbs: Advanced, Back, Details,
Forward, Less, New, Next, No, OK, Options, Previous, Properties, Settings, and Yes.

 Clear
 Use enough text to explain the command sufficiently
Don’t ignore the context and what the users get out of the action. Write what the user gets
out of the action and not what the user has to do.
 Make it concise and short
 Don't use ending punctuation
Checkboxes
Use positive and active wording so that it's clear what will happen if the user selects the
checkbox. In other words, avoid negations such as "Don't send me more email," which would
mean that the user would have to select the checkbox in order for something not to happen.
Write checkbox labels so that users know both what will happen if they select a particular
checkbox, and what will happen if they leave it clear.
If you can't do this, you can use two radio buttons, one for having the feature on, and one for
having it off, and write clear labels for each of the two cases.

Microcopy writing guidelines rakefet.zur@gmail.com Page |5

Empty states
Empty states are situations in which no data exists. There is no data to show the user in the
window, pane, or section. This could happen for several reasons, such as:
 New user, new app, or new feature
 User has cleared (or deleted) all their data
 Search that returned no results
 Error state
Use empty states to explain about a feature or app. Motivate users to perform actions and
direct them to the next action.
In each situation, users need to know what happened, why it happened, and how they can
move forward.
When you write for empty states, keep in mind what you can provide to users through empty
states:
 Educate – For both new and seasoned users, empty states are a great opportunity to guide
users on next steps or educate them on how to interact with your app. Write about what is
supposed to be or what they can do, what this feature does and how it can help them.
You can add instructions and tell users how to start using the feature or provide a link.
It’s also nice to add graphics to empty states that make them look less empty and more
inviting.
 Reward and delight – Consider what your users are trying to accomplish and design your
empty states to recognize users for their accomplishments. For example, if a user completed
all tasks or empties the spam folder, use that empty state to make them feel good about
their success!
 Reassure and assist – Things won’t always go according to plan, but that shouldn’t stop your
users from interacting with your app. If an error occurs, use that empty state to reassure
your users it’s not their fault, and give them clear, easy steps on getting back on track.
If the search returned no results, tell your users clearly that you didn’t find what they were
looking for. You can use empathy and sometimes humor in the message. Offer other
methods to search for the same thing or suggest similar phrases, items, or categories.

Waiting times
No matter how well designed your user interface may be, at some point or another, people
using it are going to have to wait for something. Waiting time is the period it takes for a system
or app to load, process data, search, download a file, and so on.
The loading time could harm the overall experience. When trying to create a faster user
experience you can shorten the perceived time rather than the actual time, that is, how fast
your content loads is in the mind of the user.
To do so, you can fill waiting times using content, animations, or actions that the user can
perform. You can:
 Let the users know what the system is doing for them. For example, update on the stages of
the process (create, import, and so on).
 If the expected waiting time is long, you can suggest that users do something else in the
meantime.
 Use humor or animation to help users pass the time.

Microcopy writing guidelines rakefet.zur@gmail.com Page |6

Placeholders
Placeholders are the text you write inside a field.
Problems
 accessibility
 not scannable
 not useful for keyboard users

Write placeholders:
• Only in very short forms
• Using humor to connect the user (only if appropriate for your product and audience)
• Placeholder information is not really required

When you need to add information or hints to a field, you can use:
• Accompanying text
 Text that appears next to or below the field
 text that opens when you click an icon next to the field label
• Dynamic help – small ToolTip that opens when you click in the field or on an icon or link next
to the field
• New page – if there is a lot of information you need to add (such as terms and conditions or
a knowledgebase article in a complex product), add a link that opens in a new tab or page

Page not found (404 pages)

You’ll need to worry about these only if you work on websites. Users encounter a 404 page
when searching for a page that no longer exists on your site (or that was never there in the first
place). There are all kinds of 40X errors.
How to write for a 40X page:
 You don’t have to specify the error number. Most users don’t know these numbers and
don’t care.
 Explain to the user what happened and how they got there.
 Show empathy (the user may be confused).
 Show them what they can do. You can add one of the following:
 Link to the home page
 Search
 Links to the main categories in the website
Remember that 404 pages usually include a picture or a graphic design. Make sure that you
don’t forget the alternate text for the image and that it lends well with the text that is displayed
on the page.

Microcopy writing guidelines rakefet.zur@gmail.com Page |7

Microcopy writing checklist
Now that you understand what microcopy and UX writing are, here’s a checklist to help you
apply some basic writing principles to your own products.
 Put the user first. Always focus on the user and on the context. Know who your user is and
what just happened and ensure your copy is useful.
 Remember the flow. Think of your messages and interactions as a conversation
 Be clear and concise. Don’t confuse your users with flowery words and complex jargon. Be
brief; Don’t account for every edge case; Cover the majority of possibilities.
 Be consistent. Use the same language and terminology across your site or app. For example,
if you ask users to “Get Started” with your product, don’t change it to “Sign Up” elsewhere.
Make sure you use the same spelling and hyphenation everywhere.
 Write for the user. Write for “you”… but don’t make it about you. The word “you” is
powerful and establishes a relationship between you and your users. Write what the user
gets out of every action and feature, not what the product does.
 Keep your voice and tone guide in mind. If you don’t have one, create a small one for your
group or product.
 Trust your instincts. If you’re not happy with what you’ve written, rewrite it. If you come
back to it later and it still doesn’t sound right, it’s likely your users will feel the same way.
 A/ B test your copy. Choose language that performs well and if you’re not sure whether
some words will be more effective than others, then A/B test them.

Useful resources
Books
 Nicely Said: Writing for the Web with Style and Purpose by Nicole Fenton and Kate Kiefer
Lee
 The Yahoo! Style Guide: The Ultimate Sourcebook for Writing, Editing, and Creating Content
for the Digital World by Yahoo! (Editor), Chris Barr
 Microcopy: The Complete Guide by Kinneret Yifrah
 Letting Go of the Words: Writing Web Content that Works (Interactive Technologies) by
Janice (Ginny) Redish

Websites
 https://www.contentharmony.com/blog/great-brand-guidelines/
 Medium – https://medium.com/tag/ux-writing
Follow people on Medium, such as https://medium.com/@jsaito
 https://www.behave.org/ - A/B testing that also has interesting examples of testing copy
 Twitter –
Follow people, such as https://twitter.com/ContentVerve?lang=en
 NN group: writing for the web: https://www.nngroup.com/topic/writing-web/
 Material design writing guidelines, Google:
https://material.io/guidelines/style/writing.html#
 UI content resources by Megan Whalin: http://meganwhalin.com/ui-content-resources/

Microcopy writing guidelines rakefet.zur@gmail.com Page |8

 Write like a human by Amy Thibodeau on Medium: https://medium.com/write-like-a-
human/write-like-a-human-61f6c7c0752c
 https://twitter.com/tinywordsmatter
 http://goodmicrocopy.com/

Groups and Forums

 https://www.facebook.com/groups/microcopy/
 https://www.linkedin.com/groups/8251547

Microcopy writing guidelines rakefet.zur@gmail.com Page |9