UX writing skill.

Words are part of the design. Vague or inflated copy makes a polished interface feel generic; plain, specific copy makes a plain interface feel trustworthy. The test for every string: does it help someone understand or act?

1. Voice

• Plain words. Write the way a helpful person would say it out loud. "Save changes", not "Persist modifications". "You're out of credits", not "Credit balance depleted".
• The user's words, not the system's. "Notifications", not "Webhook dispatch config". Name things by what people do with them.
• Short. Cut every word that does not change the meaning. Then cut again.
• Sentence case everywhere: headings, buttons, menu items, tabs, labels. "Create new project", not "Create New Project".
• Active voice, addressed to the user. "You don't have access to this project", not "Access to this project is not permitted". When the system failed, say so plainly: "We couldn't save your file", not "The file could not be saved".
• Calm. No exclamation marks except for genuine celebrations, no apologies in errors, no jokes in error states.

2. Words that make copy sound generated

Avoid these. They say nothing a reader can check:

• Verbs: unlock, unleash, elevate, empower, supercharge, revolutionize, transform, streamline, leverage, harness, reimagine, skyrocket.
• Adjectives: seamless, effortless, cutting-edge, next-generation, world-class, robust, powerful, intuitive, innovative, all-in-one.
• Phrases: "In today's fast-paced world", "Take your X to the next level", "Whether you're a X or a Y", "Say goodbye to", "Look no further".
• Shapes: three adjectives in a row ("Fast. Secure. Simple."), middle-dot lists (Design · Build · Ship), and em dashes anywhere in the product's text, including the page <title>, meta description and alt text. Use a colon, a comma or two sentences: "Ledgerline: invoices in any currency".

Replace each with a concrete fact: what it does, how fast, for whom, with what result. "Cuts a 40-minute report to 2 minutes" beats "Supercharge your workflow".

3. Headings

• A heading says the point, not the topic. "Invoices get paid 9 days faster" beats "Features". "Your workspace is empty" beats "Workspace".
• No eyebrows. Do not put a small uppercase label above a heading ("FEATURES", "PRICING", "HOW IT WORKS"). Write a heading that stands alone.
• Page titles name the page so people know where they are: "Billing", "Team members".

4. Buttons and links

• Start with a verb and name the result: "Create invoice", "Send invite", "Export CSV". Not "Submit", "OK", "Yes", "Click here", "Learn more" alone.
• Match the button to what happens next. If the button says "Publish", the toast says "Published", and the page shows the published state.
• Primary and secondary must be clearly different actions: "Delete project" and "Cancel", not "Yes" and "No".
• One to three words is ideal. A CTA can go to five if it adds a concrete benefit ("Start free, no card").
• Link text makes sense alone (screen readers list links out of context): "Read the API guide", not "here".
• Destructive actions name the thing: "Delete 3 files", "Remove Sam from team".

5. Forms

• Labels above fields, always visible. Placeholder text is not a label; it disappears when typing starts.
• Placeholders show format, not instructions: name@company.com, MM / YY. Leave them out when the label is enough.
• Helper text under the field for rules people need before typing: "At least 12 characters".
• Mark optional fields, not required ones, when most fields are required: "Company (optional)".
• Validate on blur or submit, not on every keystroke. Show the error next to the field it belongs to.

6. Errors

Every error answers two questions: what happened, and what to do now.

• Never blame the user ("You entered an invalid email"). Describe the fix ("Enter an email like name@company.com").
• Keep codes and stack traces out of the message. Put a reference ID at the end if support needs one.
• Keep what the user typed. Never clear a form because one field failed.

7. Empty states

An empty state is the first thing a new user sees. Treat it as onboarding:

1. Say what will appear here: "Invoices you send will show up here."
2. Give the one action that fills it: a primary button, "Create invoice".
3. Optional: a link to import, a template, or a short guide.

For "no results" empties, say what was searched and how to widen it: "No results for 'invioce'. Check the spelling or clear filters."

8. Loading, success and toasts

• Loading: say what is happening when it takes more than a second: "Generating report…". Use the ellipsis character.
• Success toasts: past tense of the action, plus the object: "Invite sent to sam@acme.com", "Project deleted. Undo".
• Offer Undo instead of a confirmation dialog for reversible actions. Ask for confirmation only when the action cannot be undone.
• Confirmation dialogs: the title asks the real question ("Delete 'Q3 report'?"), the body states the consequence ("This removes it for everyone. You can't undo this."), the buttons name the action ("Delete report" / "Cancel").

9. Numbers, dates and units

• Use numerals: "3 files", not "three files".
• Format with the user's locale: Intl.NumberFormat and Intl.DateTimeFormat (or toLocaleString) instead of hand-built strings.
• Relative time for recent events ("2 min ago"), absolute dates for older ones ("Mar 4"), and the full timestamp in a tooltip.
• Pluralize correctly: "1 file", "2 files", "0 files". Use Intl.PluralRules or a helper, never "file(s)".
• Keep numbers and units together with a non-breaking space (10 MB in HTML, "10\u00A0MB" in JavaScript) so they never wrap apart.

10. Realistic placeholder content

When building a design without real content, write content that looks real:

• Specific names and data: "Maya Chen, Product designer at Northwind", "$12,480.00", "Invoice INV-2041". Not "John Doe", "$XX", "Lorem ipsum".
• Realistic lengths, including some long ones, so the layout is tested: a 40-character name, a 3-line description next to a 1-line one.
• Never invent proof. No made-up customer logos, star ratings, user counts or testimonials presented as real. Use marked placeholders ([Customer quote], [Logo]) or ask the user for the real ones.
• Match the product's world. A dev tool's sample data is repos and deploys; a clinic app's is appointments and patients.

11. Accessibility in copy

• Every icon-only button gets an accessible name: aria-label="Close dialog".
• Alt text describes what an image shows when it carries information ("Bar chart: revenue up 24% since January"). Decorative images get alt="".
• Do not rely on color words alone ("click the green button").
• Expand abbreviations the first time unless the audience uses them daily.

12. Check before you finish

• No filler words from section 2, no three-adjective taglines, no em dashes in interface strings.
• Every heading states a point; no eyebrows.
• Every button starts with a verb and names its result.
• Every error says what happened and what to do.
• Every empty state explains itself and offers the next action.
• Sentence case throughout.
• Sample content is specific, varied in length, and contains no invented proof.
• Icon-only controls and meaningful images have accessible text.