Words. Most of your interface is text.

Warm-up: what do you already notice?

Before any theory, test your eye. You have used hundreds of apps, so you already have opinions about their words, even if you have never named them. Answer the three questions below quickly. Wrong answers are useful: they show you which chapters to read slowly.

Most of what a person needs to understand in your product is carried by words, so writing them is design work, and it should happen first, not last.

Try a thought experiment on the app you used most today. Replace every word with a gray bar of the same length. The layout survives. The colors survive. The icons survive. But you can no longer tell which button sends and which deletes, what the empty screen wants from you, or why the form refused your input. Now do the opposite: delete all the styling and keep only the words, in a plain list. Ugly, but still usable. That asymmetry is the whole argument of this guide. Words carry meaning; visuals carry hierarchy and mood.

The mechanism is simple. Icons and layout are good at saying where and how important. They are poor at saying what and why. A trash-can icon says "delete", but not delete what, and not whether it can be undone. Only words carry consequence, reason and instruction. Since most decisions in software are about consequence ("will this lose my work?"), most of the decision-making load sits on text.

Content first, pixels second

The usual solo workflow is: build the screen, drop in "Lorem ipsum" or "Button", ship, and fill the words in later. This reverses cause and effect. The words decide the layout: a label that needs 40 characters needs a different control than one that needs 8; an error that must explain a fix needs room under the field; a title that cannot be shortened needs two lines. When you design with fake text, every one of those constraints shows up after you have committed to a layout, and you end up cramming real words into boxes built for fake ones. That is how you get truncated buttons, three-word errors that explain nothing, and headings that say "Overview".

Torrey Podmajersky's book Strategic Writing for UX (O'Reilly, 2019) suggests a useful starting move she calls conversation-first design: before drawing anything, write the interaction as a short dialogue between the person and the product, as if two people were talking. "I want to send this invoice." "Who to? I have their email from last time." "Yes, that one." "Sent. I'll tell you when they open it." The conversation reveals what the screen must ask, in what order, and what it must say back. Then you design the screen to hold that conversation.

What "content design" means

Sarah Richards, who led the content team that built GOV.UK, uses the term content design for the whole job: working out what the audience needs, from evidence, and giving it to them at the moment they need it, in the format that suits them. That may be a sentence, a table, a calculator or no content at all. UX writing is the part of content design that lives inside the product: buttons, labels, errors, notifications. Kinneret Yifrah's Microcopy: The Complete Guide focuses on that layer: the tiny texts that decide whether someone completes a sign-up or gives up. You need both views. Content design asks "should this screen exist, and what must it say?". UX writing asks "what exact words, in what order, in how few characters?".

In the wild

• GOV.UKGovernment Digital Service, 2012–
  Replaced hundreds of department websites with one site built around plain, task-focused content. Pages start from what the user needs to do, not what the department wants to say. Content design can be the main design work, not decoration on top.
• Things 3Cultured Code, 2017
  The list names Inbox, Today, Upcoming, Anytime, Someday and Logbook explain the whole product model in six ordinary words. You understand how to use it before you open a single list. Good names are a manual you never have to write.
• Google DocsGoogle, 2006–
  A small status line near the title tells you "Saving…" and then that changes are saved. It is a few words, but it replaced the Save button and the anxiety that came with it. One status sentence can remove an entire control.
• Mailchimp Content Style GuideMailchimp, public since the 2010s
  An openly published guide covering voice, tone, grammar, and how to write each kind of message. It became the reference many teams copied. Writing your rules down is what keeps a voice consistent over years.

People do not read interfaces word by word; they hunt for the words that match their goal, so put those words first and make every line easy to skip.

In 1997 Jakob Nielsen and John Morkes tested how people read on the web. Most of them scanned instead of reading line by line. When the same content was rewritten to be concise, scannable and objective, measured usability went up by 124 percent. Later eye-tracking studies by Nielsen Norman Group found the familiar F-shaped pattern on text-heavy pages, and estimated that on an average page people read only about 20 to 28 percent of the words. GOV.UK's own writing guidance repeats that figure.

Inside an app the effect is stronger, not weaker, because people are in the middle of a task. They are not reading your settings page; they are looking for "the thing that stops the notifications". The eye moves down the left edge, reading the first one or two words of each line, and stops when it sees something that smells like the goal. Nielsen Norman Group called this the "first two words" effect: the start of each line carries most of the signal.

Front-load every line

Front-loading means putting the distinctive word at the start: "Notifications: off for this project" instead of "For this project, you have turned notifications off". It works for list items, setting labels, notification titles, email subjects, menu items and error messages. A quick test: read only the first two words of each line in a list. If you can still tell the lines apart and find what you want, the list is front-loaded.

The inverted pyramid, at interface scale

Journalists put the conclusion first, then the detail, then the background, so a reader can stop at any point and still have the most important part. Use the same order for any message longer than one line: outcome first, then the action, then the explanation. "Payment failed. Update your card to keep your plan. Your bank declined the charge on 3 May." Someone who reads three words knows the situation; someone who reads ten knows what to do.

Tools for skimmable text

• Headings that say something. "Billing" is a label; "Change your plan or card" is a heading people can act on.
• Short paragraphs. In an interface, one to three sentences. A wall of text in a dialog is a dialog nobody reads.
• Lists for parallel items. Three or more options, steps or conditions read faster as a list. Keep list items grammatically parallel.
• Bold sparingly. Bold one phrase per block at most. If everything is bold, the eye has nowhere to land.
• Numbers as digits. "3 files" is spotted faster than "three files" when scanning. GOV.UK uses numerals for this reason.
• Meaningful link text. "Read the refund policy" instead of "click here". Screen reader users often navigate by a list of links, where "click here" means nothing (see Accessible & Inclusive).

In the wild

• iOS and macOS SettingsApple
  Rows are labeled with short nouns ("Wi-Fi", "Bluetooth", "Notifications"), and longer explanations sit in smaller footer text below a group. The label is for scanning; the footer is for reading. Separate what people scan from what people read.
• GOV.UK guidesGDS
  Pages open with a summary of who the page is for, then use plain, specific headings and numbered steps. A heading should tell you whether to keep reading.
• Stripe DashboardStripe
  Payment rows show the amount and status first, with details such as the description and customer in secondary text. The thing people compare goes first and gets the strongest weight.

Use the shortest common word, the active voice and one idea per sentence, because plain text is faster for everyone, including experts, and it is the only text that survives stress, distraction and a second language.

Plain language is not simple language for simple people. It is text designed for the real conditions of use. Your reader is often on a phone, half paying attention, possibly reading English as a second or third language (true for most of your users if you sell in India or globally), and sometimes anxious because something just went wrong. Under those conditions working memory shrinks (see The Human Mind), and every unusual word or long clause costs a re-read.

GOV.UK's guidance is a good benchmark. It asks writers to aim for a reading age of 9, because by that age most people have built up their vocabulary of common words, and it notes that common words let readers handle sentences of around 25 words. It flags any sentence longer than 25 words for splitting. It also tackles the usual objection head-on: the idea that specialist audiences prefer complex language is wrong, and plain English is mandatory across the whole site. Experts read faster too. They just complain less when you make them work.

The six habits

1. Common words over formal ones. "Use", not "utilize". "Start", not "commence". The long word rarely adds precision; it adds distance.
2. Verbs over nouns made from verbs. "Choose a plan", not "make a plan selection". Linguists call these nominalizations; they hide the action inside a noun and add filler verbs like "make", "perform", "conduct".
3. Active voice. "We couldn't upload your file" names who did what. "The file could not be uploaded" hides the actor and often the reason. Passive is fine when the actor genuinely does not matter, which in error messages is rare.
4. One idea per sentence. If a sentence has "and" plus a comma plus "which", split it.
5. Positive, direct instructions. "Keep this on to get reminders" beats "Don't turn this off unless you don't want reminders". Double negatives make people stop and decode.
6. Say "you" and "we". Talking to the reader directly is shorter and warmer than "the user" or "the account holder".

A swap list to keep next to your editor

In the wild

• GOV.UK style guideGDS
  Keeps a public A to Z of preferred words and a list of words to avoid (such as "deliver" for anything that is not a parcel, and "facilitate"). A banned-word list is the cheapest style tool there is.
• Mailchimp Content Style GuideMailchimp
  Asks writers to use active voice, avoid jargon, and write for people who may be reading in a second language. Plain language and a strong brand voice are not in conflict.
• Hemingway EditorAdam and Ben Long, 2013
  A writing tool that highlights long sentences, passive voice and complex words in color, with a grade level score. Seeing the problems helps, as long as you treat the score as a hint (Chapter 15).

Voice is who your product is, and it stays the same everywhere; tone is how that same person speaks in a given moment, and it should change with the reader's feelings.

Think of a good doctor. They are the same person when they tell you your test results are clear and when they tell you they are not. Their voice (calm, direct, kind) does not change. Their tone does: lighter and brief for good news, slower, more careful and more specific for bad news. Mailchimp made this distinction popular through its Voice and Tone guide, written by Kate Kiefer Lee, which paired each kind of message with the reader's likely feelings and the tone to use. The insight was that tone is set by the reader's state, not by the brand's wish to be fun.

This matters because the same joke that delights someone who just published their first project is insulting to someone whose payment just failed. People forgive bland copy; they remember copy that was cheerful at the wrong moment.

Four dials of tone

Nielsen Norman Group (Kate Moran, 2016) described tone along four dimensions: funny to serious, formal to casual, respectful to irreverent, and enthusiastic to matter-of-fact. Thinking in dials stops tone from collapsing into a single "friendly vs professional" switch. A calm reading app, for example, might sit at serious, casual, respectful and matter-of-fact: relaxed but never jokey or hyped.

Write your voice chart

A voice chart turns vague adjectives into decisions. The classic form is three to four voice traits, each with "this, not that", plus examples. Torrey Podmajersky's version in Strategic Writing for UX goes further and ties each trait to your product principles and to concrete language choices, such as vocabulary, how wordy to be, and grammar and capitalization rules. You do not need a big document; you need a table you can check a string against.

In the wild

• MailchimpVoice and Tone guide
  Paired message types (success, error, legal, feedback) with the reader's likely feelings and the tone to use for each. The voice stays fun-but-not-silly; the tone in an error drops the fun. Tone is chosen from the reader's state.
• Mailchimp campaign sentMailchimp
  After you send a campaign, a cheerful illustration (a high five from the chimp mascot) marks the moment. It works because sending a campaign is a genuine achievement and nothing is at risk. Spend your celebration where the reader feels it too.
• Apple system alertsiOS, macOS
  Alerts are short, neutral and specific, regardless of how playful an app's marketing is. The more serious the moment, the closer every product's tone converges on plain and calm.

Recap and connect: Part one

Words carry meaning, people scan for their goal, plain text serves everyone, and voice stays while tone moves. Before moving on, connect these ideas to earlier guides.

Name things with the user's words, use one word for one concept everywhere, use nouns for things and verbs for actions, and write the names down in a glossary so they stay fixed.

Names are the most reused words in your product. A feature name appears in navigation, buttons, emails, help pages, notifications and support replies. If the name is wrong, it is wrong a thousand times. Names also build the user's mental model (see The Human Mind): when your app calls something a "project" in one place and a "workspace" in another, people reasonably assume there are two different things, and start looking for the difference.

User's words, not system words

Your database has tables, entities, jobs, tenants and payloads. Your users have clients, invoices, trips and notes. System words leak into interfaces because the person writing the UI is the person who wrote the schema. Nielsen's heuristic "match between system and the real world" names the fix: speak the user's language. Listen to how people describe the task in emails, reviews, support messages and search queries, and use their nouns.

One concept, one word

Synonyms are a virtue in essays and a bug in interfaces. In prose, repeating "project" five times feels clumsy. In an interface, switching between "project", "space" and "board" makes people believe you have three objects. The reverse is just as bad: one word for two things ("Share" meaning both "send a copy" and "invite to edit"). Decide each core term once, then use it everywhere, including in emails and support replies.

Nouns for things, verbs for actions

Navigation and headings name places and objects, so they are nouns: "Invoices", "Clients", "Settings". Buttons and menu items perform actions, so they start with verbs: "Send invoice", "Add client". Mixing the two creates small doubts. Is "Reports" a place to go or a button that generates one? Is "Export" a tab or an action? When you keep the grammar consistent, the word class itself tells people what will happen when they tap.

Naming features and products

Features can have descriptive names ("Focus mode", "Scheduled send", "Reading list") or invented ones ("Spaces", "Magic Compose", "Lens"). Descriptive names explain themselves and translate easily; invented names can become brands but must be learned. For a solo product, the default should be descriptive: you do not have a marketing budget to teach people what "Flux" means. Reserve an invented name for the one feature that is your product's identity. Name the product itself in Identity & Launch.

A starter glossary for a notes app. Five rows are enough to start; add a row every time you catch yourself hesitating between two words.

In the wild

• Twitter "favorite" to "like"Twitter, November 2015
  Twitter replaced the star "favorite" with a heart "like", saying people found the star confusing. The word and the icon changed together. A name that means different things to different people is a usability problem, not a branding detail.
• Gmail "Archive"Google, 2004
  Gmail made "Archive" a first-class action next to "Delete": hidden from the inbox, kept and searchable. Two verbs, two clear outcomes. When two actions differ in consequence, they need two distinct words.
• NotionNotion Labs
  Almost everything is a "page", and pages can contain pages. One noun covers a lot, and the model stays simple. A small, consistent vocabulary keeps a flexible product learnable.

A button label should say exactly what will happen when you press it, usually as a verb plus an object, so that someone reading only the button can act correctly.

Buttons are the most read words in a product, because they are what people read right before they commit. Often they are the only words read. In a dialog, many people skip the body text and go straight to the buttons. If the buttons say "OK" and "Cancel", the reader has to go back, read the question, and map it onto two generic words. If the buttons say "Delete 3 photos" and "Keep photos", the decision is made in one glance.

Verb plus object

"Save draft", "Send invoice", "Delete 3 photos", "Add card". The verb says what happens; the object says to what. Drop the object only when it is completely obvious from context (a single "Save" at the bottom of a single form). Add a number or name when the scope matters: "Delete 3 photos" tells you the selection worked; "Delete photo" when you selected three would be a warning sign.

Match the button to the title

In a dialog, the title asks the question and the primary button answers it with the same verb. "Delete this project?" → "Delete project". "Leave without saving?" → "Leave without saving" or "Discard changes". Matching wording lets people confirm their understanding: the verb in the title and the verb on the button are the same, so the eye links them. A mismatch ("Remove project?" → "Confirm") forces translation.

The "Cancel" trap and the second button

The secondary button needs as much care as the primary. In most dialogs "Cancel" is fine: it means "close this and change nothing". But in a dialog about canceling something (a subscription, an order, a meeting), "Cancel" becomes ambiguous: does it cancel the subscription or cancel the canceling? Write the outcome instead: "Keep subscription" and "Cancel subscription". Same for "Discard": pair it with "Keep editing", not "Cancel".

Sentence case or title case?

Sentence case capitalizes only the first word and proper nouns: "Add payment method". Title case capitalizes most words: "Add Payment Method". Google's Material Design and Microsoft's style guide recommend sentence case for interface text; Apple's guidelines have long used title case for things like menu items and some button styles. Sentence case is easier to read in longer labels, looks calmer, and avoids the endless debate about which small words to capitalize. Pick one convention per platform, write it in your style guide, and apply it everywhere. Inconsistency is worse than either choice.

More button rules that hold up

• Keep labels to 1 to 4 words, and test the longest translation (Chapter 12). German can make "Save draft" into "Entwurf speichern", which is noticeably longer.
• First person or second, not both. "Start my trial" and "Your account" in the same flow sounds like two speakers. Most products choose "you/your" for the product talking and avoid "my".
• No "Click here". It describes the mechanism, not the result, and it is wrong on touch screens.
• Say the price on a paid action. "Upgrade for ₹299/month" is clearer and more trustworthy than "Continue".
• Disabled buttons need a reason nearby. If "Publish" is greyed out, say why: "Add a title to publish".

In the wild

• macOS save sheetApple
  When you close an unsaved document, the choices are named outcomes such as "Don't Save", "Cancel" and "Save", rather than Yes, No and Cancel. Even a three-way decision becomes readable when each button names its result.
• GitHub repository deletionGitHub
  The final button repeats the action and the object ("delete this repository"), after the dialog explains what will be lost. The more serious the action, the more specific the button.
• Material Design dialogsGoogle
  Material's guidance shows dialog actions with specific verbs (for example "Discard" with "Cancel") and recommends sentence case. Both big platform systems agree: name the action.

Every field needs a visible label that never disappears, help text where a question is likely, and no essential information hidden in placeholders or tooltips.

Forms are where most products ask people for something, and where people decide whether to trust you with it. The words around a field do three jobs. The label says what goes in. The hint says how, or why you need it. The error says what went wrong and how to fix it. A placeholder (gray text inside the empty field) cannot do any of these jobs reliably, because it disappears the moment someone starts typing, which is exactly when they need it.

Why placeholders fail as labels

Placeholder-only fields look clean in a mockup. In use, they cause four problems that Nielsen Norman Group and others have documented. The label vanishes on typing, so people forget what the field was or what format it wanted. When reviewing a filled form, there are no labels to check against. Gray placeholder text can be mistaken for a pre-filled value and skipped. And light gray placeholder text usually fails contrast requirements. Try it below.

Help text: answer the question at the moment it arises

Good help text predicts the hesitation. Why do you want my phone number? Will you post to my account? What format? Is this public? Yifrah's book is full of examples where a single sentence next to a field raised completion, because it removed a worry at the exact moment it appeared. Write help text by asking, for each field, "what would make a careful person pause here?" Then answer that, in one sentence, before they have to ask.

• Format: "For example, 27/03/1994". Show an example, not a pattern like DD/MM/YYYY alone.
• Purpose: "We only use this to send your receipt."
• Consequence: "This name is shown to people you invite."
• Constraint: "Up to 25 MB. PDF or JPG."
• Optional: mark the few optional fields with "(optional)" rather than marking every required field with an asterisk, which is the GOV.UK Design System pattern.

Tooltips: for extra, never for essential

Tooltips hide text behind hover, which does not exist on touch screens, and they are easy to miss with a keyboard or screen reader if built carelessly. Use them for supplementary detail about an icon or a term. If people need the information to complete the task correctly, it belongs on the page.

In the wild

• GOV.UK Design SystemGDS
  Text inputs always have visible labels, hints sit between label and field, and the date input splits day, month and year into three labeled boxes with an example. The most tested public forms anywhere avoid placeholder labels.
• Stripe CheckoutStripe
  Card fields format the number as you type and show the card brand, so the field itself confirms the input. Sometimes the best help text is the input reacting.
• Material text fieldsGoogle
  The "floating label" pattern moves the label above the text when you type, so it never disappears. If you love the compact look, keep the label alive rather than deleting it.

A good error message says what happened, why if it helps, and exactly how to fix it, in plain words, without blame and without jokes, placed where the person is looking.

Errors are the moment your product is most likely to lose someone, and the moment they read most carefully. Nielsen's ninth usability heuristic asks that error messages be expressed in plain language, precisely indicate the problem, and constructively suggest a solution. That gives you a three-part anatomy. Most bad errors have only the first part, and many have none: "Something went wrong" tells you only that something went wrong, which you knew.

Five rules

1. Say what happened, specifically. Name the thing: which file, which field, which payment. "Couldn't save 'Q3 plan'" is better than "Save failed".
2. Say how to fix it. If the person can fix it, tell them how. If they cannot (your server is down), say what you are doing and what happens to their work: "Your changes are saved on this device. We'll retry automatically."
3. Don't blame. "You entered an invalid date" puts the person in the dock. "Enter a date in the past" or "February has 28 or 29 days" just helps. Use passive or "we" when the fault is the system's; name the person only when giving the fix ("Enter…").
4. No codes alone, no jargon. "Error 500", "null reference", "invalid token" mean nothing to most people. Translate them, then add the code in small text for support.
5. No jokes in failure. "Oopsie!" and cartoon sad faces read as flippant when someone's work is at risk. Calm and specific is the kind tone here (see the tone map in Chapter 4).

Where the message goes

Placement is half the message. Put field errors next to the field, under the input, so the eye finds them where the problem is. For a long form, also add a summary at the top with links to each field, so screen reader and keyboard users can find them. Use a page or app-level banner for problems that affect the whole screen (offline, account issue). Use a toast only for background events that do not need action, and never for errors the person must fix, because toasts disappear.

Before and after

In the wild

• GOV.UK Design System error messagesGDS
  Publishes exact wording patterns per input type, such as "Enter your date of birth" for a missing value and "Date of birth must be a real date" for an impossible one, plus an error summary at the top of the page linking to each field. Write error copy as reusable patterns, not one-offs.
• Gmail attachment reminderGoogle
  If your email mentions an attachment and you try to send without one, Gmail asks whether you meant to attach a file. The best error message prevents the error.
• Stripe API errorsStripe
  API error responses include a human-readable message alongside machine codes, and the docs explain each decline code and how to handle it. Even developer-facing errors benefit from a plain sentence.

Ask for confirmation only when an action is serious and cannot be undone, and then state the exact consequence; after any action, confirm what happened in a few specific words.

Confirmation dialogs fail because they are overused. When every action asks "Are you sure?", people learn to press the confirm button without reading, and the one dialog that mattered gets the same reflex. Undo is usually better: let the action happen, then offer a few seconds to reverse it. Save confirmation for things that are both severe and irreversible: deleting an account, a whole shared workspace, or permanently emptying the trash.

Writing a confirmation that people read

A good confirmation names the object, states the consequence in concrete terms, and offers buttons that repeat the action. Counts and names are what make people read: "Delete 'Client work'? 14 projects and 230 files will be deleted for all 6 members." The numbers interrupt the autopilot because they are new information each time. Generic text ("This cannot be undone") is identical in every dialog, so the eye skips it.

Success messages: short, specific, with a next step

"Success!" is the success version of "Something went wrong". Say what happened, where the result is, and the natural next action: "Invoice sent to ravi@gmail.com. We'll tell you when it's opened." Keep success messages quiet and short; they confirm, they do not celebrate, unless the moment is genuinely big (first publish, first sale). For reversible actions, the success message is also where Undo lives.

In the wild

• Gmail "Undo send"Google
  After sending, a small message offers Undo for a few seconds (the window is adjustable in settings). No "Are you sure you want to send?" dialog. A short delay plus Undo beats a confirmation for frequent actions.
• GitHub "Danger Zone"GitHub
  Repository settings group irreversible actions in a clearly marked section, and deletion requires typing the repository's name. Reserve friction for the few actions that deserve it, and group them.
• iOS Photos "Recently Deleted"Apple
  Deleted photos go to an album for about 30 days before being removed. The deletion confirmation can stay brief because recovery exists. A recovery path lets the copy be calm.

Recap and connect: Part two

Names build the model, buttons name outcomes, fields keep their labels, errors say what and how, and confirmations are rare and specific. Now connect these to earlier chapters and guides.

An empty screen is a chance to teach the product's next step in one sentence and one button; onboarding copy should sell the outcome, not tour the interface; and loading copy should say what is happening whenever a wait passes a second.

Every list, folder and search in your product will be empty for someone at some point. There are three kinds of empty, and each needs different words. First use: nothing exists yet, so explain what will appear here and how to create the first one. User-cleared: the person finished everything (inbox zero, all tasks done), so acknowledge it calmly. No results: a search or filter matched nothing, so say what was searched and suggest how to widen it.

Onboarding copy: outcomes, not tours

The urge in onboarding is to explain the interface: "This is the sidebar. This is where your projects live." People skip tours because they arrived with a goal, not a curiosity about your sidebar. Write onboarding around the first meaningful outcome instead: "Write your first note. It saves as you type." Use the minimum words to get someone to the moment they feel the product working (activation is covered in Problems Worth Solving). Teach the rest in context, the first time each feature becomes relevant.

• Welcome screen: one sentence of value, in the user's terms. "Turn articles into a calm reading queue." Not "Welcome to ReadLater 2.0!".
• Questions: ask only what changes the experience, and say why: "What do you mostly read? We'll suggest fonts and layouts."
• Coach marks: at most one at a time, tied to an action the person is about to take. Each one sentence.
• Skip: always offer it, and name it plainly ("Skip setup"), never guilt ("I'll figure it out myself, I guess").

Loading copy: say what is happening, honestly

Jakob Nielsen's response-time limits (from his 1993 book Usability Engineering) still hold: about 0.1 seconds feels instant, about 1 second keeps the flow of thought, and about 10 seconds is the limit of attention. Under a second, show nothing or a subtle indicator; words would flash and distract. Between 1 and 10 seconds, a short status helps ("Loading your notes…"). Beyond 10 seconds, give progress and specifics ("Importing 1,204 contacts: 380 done"), and say whether people can leave ("You can close this window; we'll email you when it's done"). Motion and skeleton screens are in Motion & Feel.

In the wild

• GitHub empty repositoryGitHub
  A new, empty repository shows quick setup instructions with the exact commands to push existing code or create a new project. The empty state is the documentation, exactly when it is needed.
• Duolingo first runDuolingo
  Lets you choose a language and start a lesson before asking you to create a profile. Show the outcome first; ask for commitment after.
• Google Search "Did you mean"Google
  When a query looks misspelled, Search suggests the corrected query rather than just reporting nothing found. A no-results state can diagnose the likely cause.

Words that reach people outside your app must earn the interruption: front-load the useful fact, make it actionable, and when you ask for permission, explain the benefit in the person's terms before the system asks.

Inside your app, people chose to be there. A notification or email arrives uninvited, on a lock screen next to messages from friends and family. Every one spends a little trust. The words decide whether that trust is repaid (useful, specific, timely) or wasted ("We miss you!"). Spend the first few words on the fact itself, because lock screens and inbox lists truncate.

Notification copy rules

• Title is the news. "Ravi paid ₹18,500", not "Payment update". The app name is already shown by the system, so don't repeat it.
• Body adds the one detail that helps decide whether to act now.
• One notification, one event. Group many events into a summary ("3 invoices paid today, ₹42,000").
• Never guilt, never fake urgency. "Your streak is about to die!" works short-term and burns trust long-term (see Honest & Calm).
• Let people control it, and say how in settings: "Payment received: on. Weekly summary: off."

Transactional emails

Receipts, password resets, invitations and alerts are often the most-read emails a product sends, and the least designed. The structure is the inverted pyramid again. Subject: the event and the key fact ("Receipt: ₹299 for Pro, May 2026"). First line: what happened. Then the details people may need later (amount, date, last four digits, invoice number). Then what happens next, and how to get help. Use a from-name people recognize. Keep one purpose per email, and make the main link a descriptive button ("Reset password"), with the link also in plain text for clients that strip buttons.

Permission prompts and priming

On iOS, the system permission alert for camera, location, contacts and similar shows a purpose string that you write (for example the value of NSCameraUsageDescription). And you generally get one chance: after someone taps "Don't Allow", the app cannot show the system prompt again, and the person has to go to Settings. Android similarly lets apps show a rationale, and repeated denials stop the prompt from appearing. So the words before and inside the prompt matter a lot.

The common pattern is pre-permission priming: before triggering the system prompt, show your own screen, at the moment the permission becomes useful, that explains the benefit in the person's terms and lets them say "Not now" without burning the system prompt. Ask in context (when they tap "Scan receipt", not on first launch), explain the benefit, and respect the no.

In the wild

• App Tracking TransparencyApple, iOS 14.5, 2021
  Apps must ask before tracking across other companies' apps and sites, with a developer-written explanation shown in the system alert. Many people say no. When the prompt is mandatory, your one sentence of explanation carries the whole decision.
• Duolingo remindersDuolingo
  Known for a persistent, playful owl persona in its reminders, which became a running internet joke. It suits a game-like product, and also shows how close playful nagging sits to guilt. Notification tone is part of your brand, for better or worse.
• Stripe receiptsStripe
  Receipt emails lead with the amount and merchant and list the payment details below. A receipt's job is to be found and understood months later.

Write numbers, dates and units the way your reader expects, let the platform format them by locale, and never build sentences by gluing strings together, because word order, plurals and length change in every language.

Numbers and units in copy

• Digits, not words, in interface text: "3 files", "2 minutes". They are faster to scan. Exception: avoid starting a sentence with a digit if your style guide prefers words there, or restructure.
• Units with a space and the standard symbol: "25 MB", "4 GB", "30 days". Be precise: "up to 25 MB per file".
• Ranges: "10 to 15 minutes" reads better in speech and screen readers than "10-15 mins".
• Money: always show the currency, the period and tax status: "₹299/month, including GST". Let the formatter place symbols and separators.
• Round for humans, keep exact for records: "about 4 minutes left" in a progress line; "₹1,23,456.50" on an invoice.

Dates, times and relative time

"03/04/2026" means 3 April in India and the UK, and March 4 in the US. Avoid all-numeric dates in interfaces; write the month as a word ("3 April 2026", "Apr 3, 2026") using the locale's order. Relative time is friendlier for recent events ("just now", "5 minutes ago", "yesterday") and worse for older ones ("143 days ago" is a puzzle). A good default: relative for the past week, absolute date after that, and the exact timestamp on hover or long-press. For anything scheduled across regions (meetings, launches, deadlines), name the time zone.

Plurals are not "add an s"

English has two plural forms for whole numbers in most messages: "1 file", "2 files". Other languages differ. The Unicode Common Locale Data Repository (CLDR) defines plural categories named zero, one, two, few, many and other. Japanese and Chinese use one form ("other") for all counts. Russian and Polish use several forms depending on the last digits. Arabic uses all six categories. Your code must not decide plurals with n === 1 ? "" : "s". Use a message format that lets each language define its own forms, such as ICU MessageFormat, and the platform's plural rules (in JavaScript, Intl.PluralRules).

Localization-ready writing

Even if you only ship in English today, writing for translation makes your English better: shorter sentences, no idioms, complete strings. The rules that matter most:

• Never concatenate. "Delete " + name + "?" assumes English word order and grammar. Use whole strings with named placeholders: "Delete {name}?", so a translator can move {name} where their language needs it.
• Plan for expansion. Translated text is often 30 to 40 percent longer than English on average, and very short strings can double or more. "Edit" can become "Bearbeiten". Never size buttons to the English word.
• Avoid idioms and puns. "Hit it out of the park", "piece of cake", "it's a wrap" do not translate, and often confuse non-native English readers too.
• Don't reuse a string in two places just because the English matches. "Open" (an adjective: the file is open) and "Open" (a verb: open the file) are different words in many languages. Give each its own key.
• No text in images. It cannot be translated, resized or read by screen readers.
• Give translators context: a comment per string saying where it appears and any length limit.

In the wild

• JavaScript Intl APIsECMAScript Internationalization API
  NumberFormat, DateTimeFormat, RelativeTimeFormat, PluralRules and ListFormat are built into modern browsers and Node, backed by CLDR data. You do not need a library to format correctly for most locales.
• ICU MessageFormatUnicode ICU
  A widely used syntax for messages with plurals and selections, supported by libraries on most platforms. Choose a format that lets each language define its own plural forms.
• GOV.UK date styleGDS
  Uses dates like "4 June 2026", without ordinals like "4th", and the 12-hour clock with "am" and "pm". A written date rule removes a whole class of ambiguity.

Around money, data and leaving, say the specific fact people are afraid you are hiding: the full price and when it is charged, what you collect and why, and exactly how to cancel.

Trust copy works on a simple mechanism. People arrive at a pricing page, a sign-up form or a cancel screen with a suspicion: "there's a catch". Every vague phrase ("Unlock premium", "We value your privacy", "Manage subscription") confirms the suspicion, because vagueness is what a catch looks like. Every specific fact ("₹299 a month after the 14-day trial. We'll email you 3 days before.") disarms it. Specifics are not only clearer; they are evidence that you have nothing to hide.

Pricing copy

• Say the real price and period, including tax where the buyer expects it: "₹299/month incl. GST" or "$8/month, billed yearly ($96)".
• Say when money moves: "You won't be charged today. Your trial ends 14 March; then ₹299/month."
• Promise and keep a reminder before a trial converts. In India, RBI rules for recurring card payments already require a pre-debit notification before each charge; a friendly reminder is good practice everywhere.
• Name plan differences in outcomes, not feature codes: "Unlimited invoices" beats "Pro tier quota uplift".
• Put the cancellation path next to the price: "Cancel any time in Settings → Plan."

Privacy copy

"We value your privacy" is the most ignored sentence on the internet, because everybody says it. Privacy copy earns trust only when it is specific and placed at the moment of collection. Next to a field, say what you use it for. In settings, describe what each toggle actually shares. In your privacy policy, start with a plain summary: what you collect, why, who sees it, how long you keep it, how to delete it. And only say "we never sell your data" if it is true and will stay true.

Cancellation and leaving

The cancellation flow is where many products reveal their real voice. The honest pattern: a clearly labeled path ("Cancel plan" in Settings), one screen that states what happens and when ("You'll keep Pro until 30 June; your notes stay; export any time"), an optional one-question survey, and a final button that does what it says. You may offer an alternative once (pause, a cheaper plan), as an equal option, not as a maze. Regulators in several countries have acted against hard-to-cancel subscriptions; for example, the US Federal Trade Commission sued Amazon in 2023 over how Prime sign-up and cancellation worked. But the stronger reason is simpler: people who leave easily are the people who come back and recommend you.

In the wild

• App Store subscriptionsApple
  Subscriptions bought through the App Store can be viewed and canceled from one place in the account settings, with the renewal date shown. A predictable cancel location builds trust in buying in the first place.
• App privacy labelsApple App Store, December 2020
  Apps show a standard summary of the data they collect, in categories, before download. A short, structured summary beats a long policy for most decisions.
• "Confirmshaming"Named on Harry Brignull's deceptive patterns catalog
  Decline options worded to make people feel bad ("No thanks, I prefer paying full price"). Catalogued as a deceptive pattern. If your decline label would embarrass you read aloud, rewrite it.

Write so that nobody using your product feels excluded, assumed about or talked down to: neutral words for people, no assumptions about bodies, names, genders or cultures, and no "just" or "simply" that make struggle feel like failure.

Inclusive language is not a list of forbidden words; it is the habit of noticing who your words assume. Every interface sentence carries assumptions: that the reader is a man ("Hey guys"), that everyone has a first name and a surname, that a task is easy for everyone ("simply drag the file"), that everyone celebrates the same holidays, that "blind" and "crazy" are fine metaphors. When an assumption is wrong for a reader, the product tells them, in a small way, that it was not made for them.

Where assumptions hide

Names and forms

Forms encode assumptions most directly. Many people have a single name (common in parts of South India and Indonesia, for example), family names that come first, names with spaces or apostrophes, or names longer than 30 characters. The W3C's article "Personal names around the world" walks through these cases. A single "Full name" field that accepts any characters, plus an optional "What should we call you?", works for nearly everyone. Ask for gender, title or date of birth only if you truly need them, and say why.

"Just" and "simply"

Help text often says "Just connect your account" or "Simply drag the file here". To the writer it sounds encouraging. To a reader who is stuck, it says the task is trivial and they are failing at it. These words add nothing to the instruction; deleting them makes the sentence shorter and kinder at once. The same goes for "obviously", "of course" and "easy". Let the person decide what is easy.

In the wild

• GitHub default branchGitHub, October 2020
  Changed the default name for new repositories' primary branch from "master" to "main". Many tools followed. Even deeply technical terms can be changed when a better word exists.
• Microsoft Writing Style GuideMicrosoft
  Includes a section on bias-free communication covering gender-neutral alternatives, people-first or identity-first language, and examples that reflect diverse people. Write your own short version; you do not need to invent the rules.
• W3C "Personal names around the world"W3C Internationalization
  An article explaining how names vary across cultures and what that means for form design. Read it once and you will never build a required last-name field again.

Recap and connect: Part three

Empty screens teach, waits explain, notifications earn their interruption, permission prompts explain benefits in context, numbers follow the reader's locale, trust comes from specifics, and inclusive words avoid assumptions.

Your first draft is always too long; cut in rounds, read every string aloud, and use readability scores as a smoke alarm, not as a judge.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.William Strunk Jr., The Elements of Style

Strunk's rule, "Omit needless words", is the most useful single sentence about interface writing, even though it was written for students decades before screens existed. Steve Krug turned it into his third law of usability in Don't Make Me Think: get rid of half the words on each page, then get rid of half of what's left. Both are deliberately extreme. The point is not a word count; it is that most first drafts carry words that make the reader work without giving them anything.

There is a limit, and you need to know it. Concise is not the same as shortest. "Saved" is shorter than "Saved. Your changes are on all your devices", but if people worry about sync, the second one does more work. Cut words that carry nothing; keep words that answer a question. The test is not "can I delete this?" but "would anyone miss this?".

Three rounds of cutting

Readability formulas, and their limits

Rudolf Flesch's Reading Ease score (1948) and the Flesch-Kincaid Grade Level (developed for the US Navy in 1975) are the most common formulas. Both use only two inputs: average sentence length in words, and average word length in syllables. Grade Level = 0.39 × (words per sentence) + 11.8 × (syllables per word) − 15.59. Tools like Hemingway Editor and many CMS plugins show these scores. They are useful because long sentences and long words really do slow people down.

But look at what the formulas cannot see: meaning, order, logic, jargon that happens to be short ("API", "fork", "ping"), and context. A two-word button is not a sentence. "Do not not turn off sync" scores beautifully and is nonsense. A score tells you where to look; only reading tells you what is wrong.

The read-aloud test

Reading aloud is the single best editing tool you own, and it is free. Your ear catches what your eye skips: sentences that run out of breath, words you would never say ("utilize", "kindly"), a robot tone, repeated words, missing words. Read every new string aloud before you commit it. Better: read the whole flow aloud as the conversation from Chapter 1. If you would be embarrassed to say a line to a customer standing in front of you, rewrite it.

In the wild

• Hemingway Editor2013
  Colors hard-to-read sentences, adverbs and passive voice, and shows a grade. Many writers use it as a first pass. A highlighter is more useful than a score, because it points at sentences.
• GOV.UK content reviewGDS
  Content designers review each other's work in pairs (often called "2i", a second pair of eyes) before publishing. Alone, a weekly read-aloud is your second pair of eyes.
• Apple release notesApple
  App Store "What's New" notes from careful developers lead with the user-visible change in one sentence, not "Bug fixes and performance improvements". Even the most skipped text is a chance to sound like a person.

Treat words as a system: audit what you have, write before you draw, keep every string in one organized place in code, and check new words against your voice chart and glossary before they ship.

Teams have content designers, style guides and review steps. You have yourself and a codebase. That is enough, if you put the words where you can see them all at once. The biggest problems in product copy are not individual bad sentences; they are inconsistencies between sentences written months apart, and gaps (states nobody wrote). Both are invisible when strings are scattered across components. Both become obvious in a single file or a single spreadsheet.

Step 1: the content audit

A content audit is an inventory of every piece of text in your product, with a judgment on each. Sarah Richards' Content Design describes audits as the starting point for any content work: you cannot improve what you have not listed. For an app, export your strings (or walk every screen with a spreadsheet open) and record, for each one: where it appears, its type (button, error, empty state…), the text, and any issue you see against this guide.

Step 2: content-first prototyping

For new features, reverse the usual order. Write the conversation (Chapter 1), list every string the feature needs including every state (empty, loading, error, success, permission), then sketch the screens around those strings, then build. Michael Metts and Andy Welfle's book Writing Is Designing (2020) argues exactly this: writing is a design tool for working out what the product should do, not decoration added after. When you code the screen, paste the real strings in from the start.

Step 3: organize strings in code

Put every user-facing string in one file per language (JSON, YAML, .strings, strings.xml, whatever your platform uses). Key strings by meaning, not by position: invoice.send.button rather than screen3_button2, so a key still makes sense after a redesign. Add a short comment for context and length limits. Use named placeholders and plural-aware messages. Now your whole product's voice fits in one scrollable file you can read, search, diff and hand to a translator.

{
  "invoice.send.button": "Send invoice",
  "invoice.send.success": "Invoice sent to {email}. We'll tell you when it's opened.",
  "invoice.send.error.bounced": "We couldn't deliver to {email}. Check the address, then send again.",
  "invoice.list.empty.title": "No invoices yet",
  "invoice.list.empty.body": "Invoices you send will appear here.",
  "invoice.list.count": "{count, plural, one {# invoice} other {# invoices}}",
  "invoice.delete.title": "Delete invoice {number}?",
  "invoice.delete.body": "It will be removed for you and {client}. You can't undo this.",
  "invoice.delete.confirm": "Delete invoice"
}

Keyed by meaning, grouped by feature, every state present, placeholders named, plurals handled. Reading this file top to bottom is a content review.

Step 4: keep it consistent

• Your style guide is words.md: voice chart, tone map, glossary, banned words, date and number rules, capitalization rule. One page is enough.
• Lint the string file: a tiny script that fails the build on banned words ("Submit", "invalid", "simply", "successfully", rival synonyms from your glossary) costs an hour and runs forever.
• Review the diff: before each release, read the changed strings aloud (Chapter 15).
• Screenshot review: occasionally look at every screen with real data and the longest strings, to catch truncation.

AI-assisted writing: useful, with three traps

Language models are good at producing variants quickly: five ways to say an error, a shorter version of a help paragraph, a first draft of an email. Use that. But they bring three traps. First, a default voice: generic, upbeat, adjective-heavy ("Seamlessly unlock powerful insights!"), which is nobody's voice and certainly not your calm one. Second, inconsistency: a model does not know your glossary unless you give it, so it will happily call a "notebook" a "folder". Third, invented facts: help text that describes a setting that does not exist, or a limit you never set. Give the model your voice chart and glossary, ask for options rather than answers, and edit every output against this guide. Designing AI features themselves, including how they should talk, is covered in Designing with AI.

In the wild

• GOV.UKGDS
  Built its content around user needs, a public style guide and peer review, and published how it works so others could copy it. Process, written down, is what keeps thousands of pages consistent.
• Platform string filesiOS, Android, web i18n libraries
  Every major platform supports external string files with comments and plural rules (Apple's String Catalogs, Android's strings.xml with plurals, and ICU-based libraries on the web). The tooling to organize words already exists; use it from the first screen.
• Mailchimp Content Style GuideMailchimp
  Released publicly under a Creative Commons license, so others can adapt it. Start from a good public guide and cut it down to what your product needs.

Wrap-up

Practice assignment for the next two weeks

About 30 minutes a day. Every day ends with something added to words.md or your string file.

1. Day 1. Gray-bar test and string inventory of your busiest screen (Exercise 1.1).
2. Day 2. Two-word scan on three lists (Exercise 2.1).
3. Day 3. Plain-language sweep and banned-word list (Exercise 3.1).
4. Day 4. Voice chart and tone map (Exercise 4.1).
5. Day 5. Glossary and synonym fixes (Exercise 5.1).
6. Day 6. Button audit (Exercise 6.1) and form words pass (Exercise 7.1).
7. Day 7. Rest. Notice the words in three apps you use; collect one great and one bad example.
8. Day 8. Error inventory and rewrite of the top ten (Exercise 8.1).
9. Day 9. Confirmation triage and success messages (Exercise 9.1).
10. Day 10. Empty states and loading copy (Exercise 10.1).
11. Day 11. Notifications, emails and permissions (Exercise 11.1).
12. Day 12. Localization smell test (Exercise 12.1) and trust review (Exercise 13.1).
13. Day 13. Assumption audit (Exercise 14.1) and the halving exercise (Exercise 15.1).
14. Day 14. Audit, centralize and lint (Exercise 16.1). Read your whole string file aloud. Compare it with your Day 1 inventory and write three sentences on what changed.

Reading list

• Strategic Writing for UX
  Torrey Podmajersky, O'Reilly, 2019 · The most practical book on writing interface text, with voice charts, conversation-first design and patterns for each kind of UI text.
• Microcopy: The Complete Guide
  Kinneret Yifrah, 2017 (2nd edition 2019) · Hundreds of examples of forms, errors, empty states and buttons, with the reasoning behind each.
• Content Design
  Sarah Richards, 2017 · From the person who led GOV.UK's content team. Read it for user needs, audits and the discipline of writing only what people need.
• Writing Is Designing
  Michael J. Metts and Andy Welfle, Rosenfeld Media, 2020 · How to use words as a design tool from the first sketch, with a strong section on voice and on working inside product teams.
• Nicely Said
  Nicole Fenton and Kate Kiefer Lee, 2014 · Warm, readable guide to writing for the web with a clear voice, from one of the people behind Mailchimp's Voice and Tone.
• The Elements of Style
  William Strunk Jr. and E. B. White · Short and old, still the best training in cutting. Read "Omit needless words" and the section on active voice.
• Don't Make Me Think
  Steve Krug · Read the chapter on omitting needless words and the third law of usability for the interface version of Strunk.
• Mailchimp Content Style Guide
  Mailchimp, free online · A complete, public style guide you can adapt; especially the voice and tone and the writing-for-accessibility sections.
• Writing for GOV.UK and the GOV.UK style guide
  Government Digital Service, free online · The plain-language benchmark: reading age, sentence length, words to avoid, and the A to Z of style.
• How Users Read on the Web
  Jakob Nielsen, 1997, Nielsen Norman Group · The study behind "write for scanning", still worth reading for the method as well as the result.
• Personal names around the world
  W3C Internationalization · Short article that will change how you design every name field.
• Microsoft Writing Style Guide
  Microsoft, free online · A thorough reference for UI terms, capitalization and bias-free communication.

Next, carry these words into every state your product has: Accessible & Inclusive builds directly on the plain-language, link-text and form chapters here.