UX Writing & Microcopy

Every word in an interface is a design decision. Button labels, error messages, empty states, onboarding steps — they all teach the user how the product works. Generic copy teaches nothing.

The Principles

1. Clear over clever. "Submit" is clearer than "Let's go." "Save changes" is clearer than "Done." Users scan — they don't read. Make the scan work.
2. Action-oriented. Start with the verb. "Create project" not "Project creation." "Delete account" not "Account deletion."
3. Specific over vague. "Your file report.pdf is too large (max 10MB)" beats "File too large." "Enter your work email" beats "Enter email."
4. One idea per message. Error messages explain ONE problem and ONE fix. Not three possible causes.
5. Match the tone to the context. Error messages: empathetic, solution-focused. Empty states: encouraging, action-oriented. Success: brief, celebratory (but not over-the-top).

Button Labels

The Rule

The button label should complete the sentence "I want to ___"

Primary vs. Secondary

• Primary button: the main action. Use a specific verb: "Create project", "Save changes", "Send invitation".
• Secondary button: the alternative. "Cancel", "Discard", "Go back".
• Danger button: destructive action. "Delete project", "Remove member". Always red/warning colored.

Never Use

• "Submit" (what am I submitting?)
• "Click here" (where does it go?)
• "OK" / "Confirm" (what am I confirming?)
• "Learn more" (about what? Link to what?)

Instead: "Create account", "Download report", "View pricing", "Read the guide".

Error Messages

The Formula

[What went wrong] + [Why, if useful] + [What to do next]

Rules

1. Never blame the user. "You entered the wrong password" → "Incorrect password. Try again or reset it."
2. Never show raw error codes without human explanation. "Error 500" means nothing to users.
3. Never leave the user stuck. Every error message must suggest a next action.
4. Be specific about what failed. "Couldn't upload avatar.jpg" beats "Upload failed."
5. Keep it short. One sentence for the problem, one for the fix. Max.

Empty States

Empty states are the first thing new users see. They should teach, not just inform.

The Formula

[What goes here] + [Why it's empty] + [What to do about it]

Rules

1. Always include a call-to-action if there's something the user can do.
2. Use the empty state to teach what the feature does.
3. Keep the tone encouraging — empty states shouldn't feel like failures.
4. Show an illustration or icon to make the state feel intentional, not broken.

Form Validation

Inline Validation

Validate on blur (when user leaves the field), not on every keystroke. Keystroke validation feels like being watched.

Success States

After form submission:

• Inline: "Saved" or a checkmark next to the field.
• Page-level: "Your changes have been saved" toast or banner.
• Redirect: "Project created! Here's your new project." with a link.

Onboarding

The Progressive Disclosure Pattern

Don't explain everything upfront. Teach one concept at a time, in context.

1. Welcome screen: one sentence about what the product does. One CTA.
2. First action: guide the user to their first success (create a project, invite a teammate).
3. Contextual tips: show tips when the user reaches the relevant feature, not before.
4. Checklist: for complex products, a progress checklist ("3 of 5 steps complete") motivates completion.

Onboarding Copy Rules

• Max 3 sentences per step. If it takes more, the step is too complex.
• Show, don't tell. A screenshot or animation beats a paragraph.
• Let users skip. "Skip tutorial" should always be visible.
• Celebrate completion. "You're all set! Here's what to do next." with clear next steps.

Notifications & Toasts

Rules

• Don't stack more than 3 toasts. If there are more, group them: "5 new notifications."
• Success toasts auto-dismiss. Error and warning toasts stay until the user acts.
• Include an undo option for destructive actions: "Project deleted. Undo"

Voice & Tone

The Four Dimensions

Rules

1. Pick a lane and stay in it. Don't mix formal error messages with playful empty states.
2. Match the stakes. Error messages should be more serious than success messages.
3. Cultural sensitivity matters. Humor doesn't translate. When in doubt, be restrained.
4. The product's audience determines tone. A banking app is more formal than a game.

Localization Considerations

• Don't concatenate strings. "Delete " + project_name + "?" breaks in languages with different word order. Use interpolation: "Delete {name}?"
• Allow for text expansion. German text is typically 30% longer than English. Design buttons and labels to accommodate.
• Date and number formats vary by locale. Use Intl.DateTimeFormat and Intl.NumberFormat.
• Pluralization is complex. "1 item" / "2 items" works in English but not in Arabic (which has 6 plural forms). Use Intl.PluralRules.

Anti-Patterns

• "Are you sure you want to ___?" in confirmation dialogs. The buttons should make the action clear: "Delete project" / "Cancel" — not "Yes" / "No."
• Jargon in user-facing copy. "Authentication failed" → "Incorrect password."
• Passive voice. "The file was deleted" → "We deleted the file" or "File deleted."
• Double negatives. "Don't not save" → "Discard changes?"
• Emoji in error messages (unless the product tone is explicitly playful).
• Exclamation marks everywhere. One per page max. Not every success is "Amazing!"
• Lorem ipsum in production. Write real microcopy — it teaches the user and documents the design.