UX writing for teams that do not have a writer

UX writing for startups is the button, the error, and the empty state. Name the action, say what happens next, and cut the mood that hides the fact.

By
A close view of a fountain pen writing on lined paper. The slow handwriting sits with a piece about the short lines a product still has to get right.
A pen on paper, where a label gets another pass. Photograph via Unsplash.

UX writing for startups is the labels, buttons, errors, and empty screens. A team without a writer still has to ship those lines. The method is small enough to do on the interface itself: name the action, say what happens next, and cut the mood. Voice is a later polish. Clarity is the first pass.

You do not need a content department to do this. You need one person who will read the words aloud and one rule the team will keep when the deadline arrives. The rule is that the interface speaks in actions and outcomes. Jokes, slogans, and internal codenames can wait outside the product.

Name the action

A button should say what will happen when it is pressed. "Save lead," "Send invoice," "Discard draft." "OK," "Submit," and "Continue" are weak because they hide the verb. If two buttons can both be clicked, each one needs its own verb. "Save" and "Save and notify" tell the truth. "Yes" and "No" push the meaning up into a question the person may not have read.

Use the team's real noun. If the product calls them leads, the button says lead. If customers call them clients, the button says client. Pick one. The navigation, the page title, the button, and the error all use it. A startup accumulates synonyms because each screen was written on a different day. A single hour of search-and-replace across the file is often the highest-value writing you will do this month.

Links are buttons with a different shape. "Click here" says nothing. "Read the pricing notes" says where the person is going. If the link leaves the product, say so when the surprise would matter: "Open the bank's site." People can forgive a new tab. They should not have to guess.

Icons need a name too, visible or available to a screen reader. A magnifying glass with no word is a bet that everyone shares your metaphor. Put "Search" beside it until the people who use the product no longer need the word. You can remove the visible word later. You should not start without it.

W3C's Web Content Accessibility Guidelines include "understandable" among the four principles of accessible content, with testable success criteria underneath. Labels and instructions are part of that principle: when a field expects input, the name of the field has to be available, not merely hinted by placeholder text that vanishes as someone types. Write the label. Keep it visible. Use the placeholder for an example, such as a sample email, if you need one at all.

Say what happens next

A person in a purple shirt typing on a bright blue laptop at a round table. It accompanies an article about UX writing for teams that do not have a writer.

Every action has an aftermath. The writing should preview it when the aftermath is not obvious, and confirm it when the action completes.

Preview belongs on destructive or surprising actions. "Delete the lead. The call history goes with it." Put that sentence next to the button, not in a tooltip the person might miss. If the action can be undone, say the window: "You can restore this until tomorrow." If it cannot, say that once, plainly.

Confirmation belongs in the success line and in the object. "Invoice sent to Northwind." Then show the invoice marked sent. Nielsen Norman Group's research on reading behavior is the reason to stay short: people have time to read only about a quarter of the text on a page they visit. A success paragraph will be skipped. A success sentence might be read. Spend the sentence on the outcome, not on congratulations.

Errors are the same pattern in a harder moment. Name the failure, the cause you actually know, and the next action. "Could not send the invoice. The tax number is missing. Add it and try again." Cut "oops," cut "uh oh," cut a joke about the server having a bad day. Mood in an error makes the person do extra work to find the instruction.

Empty screens follow the pattern too. "No invoices yet. Create the first one." The button repeats the verb. A witty empty state that does not name the action is a poster. Posters belong in the brand, not between the person and the job.

System status is a cousin of confirmation. "Saving…" and "Saved" should use the same verb as the button. If a process takes long enough to wonder, say what is happening and whether they can leave. "Sending 40 invoices. You can close this page." Uncertainty is worse than a plain wait.

Cut the mood

Mood is the adjective, the exclamation, the mascot's catchphrase, the apology that sounds like a brand campaign. It feels like personality. In a short interface it usually displaces the verb.

Read a line and delete any word that does not change what the person knows or can do. "Successfully" can often go, because the sentence "Invoice sent" is already the success. "Just" and "simply" scold. "Please" is optional and sometimes kind on a request for a favor; it is clutter on every button. "Are you sure you want to" is a stall in front of a verb you could have written: "Delete the lead."

Keep a small file of lines you are willing to say, and lines you are not. Three of each is enough for a young product. Willing: short, specific, calm. Unwilling: jokes during errors, fake urgency, pet names for the user, metaphors that require the marketing site to decode. When someone proposes "Let's get cooking" as the label on a create button, the file settles the argument without a debate about brand feelings.

This is not a ban on warmth. Warmth is a tone you can hear in a clear sentence. "You're set. Alex Kim is on the list." That line is friendly because it is specific. It does not need a party emoji to prove it. If the brand is quiet, the product should be quiet. Wabisabi, a public brand site, shows how a calm voice can be a decision rather than an absence. A product from the same kind of company should not suddenly become loud in its buttons.

Cut internal language with the same knife. Sprint names, database columns, and jokes from the codebase leak into labels when the team is tired. "Sync the hubspot_id" is not a button. Name the outcome the user would recognize, and keep the column name in the code.

A pass you can run this week

Smooth overlapping waves of blue, violet, and warm orange. It accompanies an article about UX writing for teams that do not have a writer.

Take one workflow. Paste every string into a list: navigation, headings, fields, buttons, empty, success, error, permission. Read them in order, aloud. You will hear the synonym and the missing verb immediately.

Then mark each line with one of three notes.

  1. Keep. It names the action or the outcome.
  2. Rewrite. It has a mood, a synonym, or a vague verb.
  3. Add. The state exists in the product and the line is still a default from the framework.

Rewrite the marked lines in one sitting so the nouns stay consistent. Put the new lines back in the product the same day. A spreadsheet of better copy that never lands is a wish.

Check the longest and the shortest cases. A button that says "Save and notify the account owner" may break the layout. Shorten the visible label only after the meaning is safe, and keep the full meaning in the accessible name if you truncate. "Notify owner" with a nearby sentence is better than a button that wraps into unreadability.

Do this pass before you argue about type. Words change the layout. A truthful label is often longer than "Submit." Let the layout adjust. Shrinking the truth to fit a too-small button is how the vague verb sneaks back.

If the pass surfaces a voice you want on the marketing site as well, that is a larger piece of work. The sentences a company is willing to say, and the ones it refuses is the next article. The product pass above can happen first, this week, with the team you already have.

When you want the interface and the words considered together, look at Hanabi's services. Bring the workflow and the list of strings. The rough list is a better brief than a request for "better UX copy."

Frequently asked questions

What should a button say?

Say the verb and the object: save the lead, send the invoice, discard the draft. Avoid OK, Submit, and Continue when they hide the action. Use one noun for the thing across the navigation, the button, the success line, and the error. Synonyms from different days are the usual mess.

How short should interface copy be?

Short enough to say the action and the outcome, and no shorter if the truth needs another word. People read little of the text on a screen, so a success sentence beats a paragraph, a joke, or a word like simply. A specific line is already a kind of warmth.

Can a team do this without a dedicated writer?

Yes. Paste every string from one workflow into a list, read them aloud, and mark what to keep, what to rewrite, and which states still use a framework default. Put the new lines back the same day, because a spreadsheet that never lands in the product does not change the interface.

Sources and further reading

  1. WCAG 2 Overview, W3C Web Accessibility Initiative
  2. How Long Do Users Stay on Web Pages?, Nielsen Norman Group

Written by

Hanabi

Hanabi is a product design and web development studio. The studio writes about clear websites, brand systems, and product interfaces for founders.

Keep reading

All articles