Better UX Writing
by Parker · 89 things on NewTwos
- UX writing is read by users while using the product
- UI text, emails, text messages, accessibility (a11y) labels
- UX text should make the user feel good
- UX text should be written to be understood by the average 5th grader
- We maintain a standard to maintain user's confidence and trust in the product
- Length (Scanability)
- Reducing repetition and redundancy reduces reading resistance
- Ex. Create a new file -> Create a file, 12 items total -> 12 items, 10 items were successfully copied -> 10 items were copied
- English is 33% shorter than other languages. Use this to test other languages for truncation
- Stay in the present when you can. Changing tense adds length and cognitive load
- Remove modifiers and empty phrases
- Detail that doesn't help the user decide what to do is distracting
- Long words sound stuffy
- Ex. utilizes -> uses, additional -> more, enables -> lets
- Voice (Emotional response)
- Don't be a robot: don't skip articles, use contractions, don't talk about the machine's innards (talk about what the user is experiencing, talk from the user's perspective)
- People engage more easily with other people, not machines
- Speak directly to the user
- When you're spoken to directly, you don't have to figure out if it applies to you
- Don't be passive aggressive, it is subtly insulting to the user
- Ex. Are you sure you want to delete this message? -> Delete this message? or Do you want to delete this message?, Name is too long -> Name can be up to 12 characters
- Don't make light of difficult situations, praise users for completing common tasks, or embarrass them
- Clarity (Comprehension)
- Use your audience's vocabulary
- Don't make users translate unfamiliar jargon, don't force terminology on users
- Ex. Credentials -> Username and password, Configure -> Set up, Verify -> Authenticate
- Use active voice when the user performs the action
- Focus on the user, don't make the system the subject
- Prefer verbs over nouns over adjectives
- Verbs catch and hold readers' attention better
- Ex. New -> Compose, Title -> Add a title, End presentation -> Stop presenting
- Use short sentences. It is okay to break sentences into fragments
- Simple words are easier to read, understand, and translate
- Use abbrevs only when necessary
- Watch out for ambiguity. Ambiguity only exists in the mind of the reader, not the writer
- User might or can instead of may
- Benefit (Usefulness)
- Talk about what the user needs, not what the product needs or is doing
- Password must contain... vs Enter a secure password...
- Loading... -> Getting your items...
- Users are put off by text that talks about arbitrary restrictions imposed by the system
- Guide, don't teach
- User's aren't here to learn, they're here to get things done
- Don't set off false alarms
- Use notifications sparingly, don't imply problems
- Don't tell the user what they can see. Don't make the user worry about things they can't do anything about
- Don't try to cover your back or be polite just to seem nice
- Don't say please or sorry
- Don't worry about how users feel about us, worry about meeting their needs
- Help the user recover
- Point out how to fix the issue in the error message
- A bare error message is useless because there's nothing a user can do about it except feel bad
- Consistency (Confidence)
- Use proper punctuation. Watch your periods and commas
- We don't need periods at the end of sentences that is alone
- Use as little punctuation as possible
- We do use the Oxford comma
- Use an ellipsis only to tell the user to wait, and then only if there's no graphical in-progress symbol
- Don't use exclamation marks to try to excite the user
- Put user-supplied text and multiword control names in (curly) quotes to show where they begin and end
- Use sentence caps everywhere
- Don't invent Proper Nouns to make features seem important
- Tighten the text
- No repeated words
- No redundant words (create a new widget)
- No adjectives or adverbs that aren't necessary for the understanding of the text
- No empty phrases (there are, if you want)
- No questioning the user's judgement (are you sure, do you really want)
- No unnecessary details
- No unnecessary verb tense shifts
- No long, pretentious words (utilize > use, additional > more, display > show, modify > change)
- No Jargon (load, initialize, domain)
- No long, sentences, or sentences that can be replaced with a phrase
- No error messages without a fix or workaround
- Checking the text?
- Does it have a verb if it's a CTA (new file -> create a file)
- If a sentence or a verb phrase, can it be written using active voice?
- Can you add articles (a, an, the) for clarity and conversational voice?
- Does the text speak from the user's perspective (see more) instead of the machines's (load more)?
- Does the text respect the user by not trying to be funny or faddish?
- Are there ambiguous words or phrases? Have you checked with someone unfamiliar with your product?
- Does it use the words should, please, or sorry unnecessarily?
- Polish the text
- Is the punctuation correct? Make sure periods and commas are used correctly (see comment)
- Does it use sentence capitalization?
- Can you replace verb phrases with a contraction? Especially look for not and is
- Is the spelling correct?
- Have you checked your terminology at go/googleuxwords and your product's list?
- UX = interactions + visuals + motion + words