Write the words inside an interface (labels, buttons, errors, empty states, microcopy) so they are clear, concise, and helpful. Use when writing or reviewing any text a user reads while using a product.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add Amey-Thakur/AI-SKILLS --skill ux-writing --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ux Writing?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-ux-writing)More formats (shields.io, HTML) on the badges page.
---
name: ux-writing
description: Write the words inside an interface (labels, buttons, errors, empty states, microcopy) so they are clear, concise, and helpful. Use when writing or reviewing any text a user reads while using a product.
---
# UX writing
The words in an interface are part of the design. A button label, an error
message, an empty-state line: each guides or confuses a user mid-task. UX
writing is writing under the tightest constraint (space, and a user who
does not want to read), where every word must earn its place and do a job.
## Method
1. **Be clear above clever.** The user is trying to do something, not read
your copy. A button that says exactly what it does ("Delete account")
beats a witty one ("Say goodbye?"). Cleverness that costs a moment of
confusion is a bad trade in an interface (see clear-writing). Save
personality for where it does not block the task (see voice-and-tone).
2. **Write actions as verbs the user is taking.** Buttons and links say
what happens: "Save changes", "Send invite", "Download report", not
"OK", "Submit", or "Yes". A specific action label removes doubt about
what a click does and reduces mistakes (see interaction-design).
3. **Make errors helpful, not blaming.** State what went wrong and, above
all, what to do about it, in plain language: "That email is already
registered. Sign in instead?" not "Error 422: constraint violation".
Never blame the user; never expose internals (see empty-and-error-states,
error-messages). The error message is a moment to help, not scold.
4. **Cut every word that does not help.** Interface text is read in
glances; trim to the essential ("Enter your email" over "Please enter
your email address in the field below"). Placeholder, helper, and label
text should not repeat each other (see concise-writing).
5. **Guide empty and first-run states.** An empty screen is a chance to
tell the user what goes here and how to start, not a dead end (see
empty-and-error-states, onboarding-ux). The first thing a new user sees
should orient and invite the first action.
6. **Stay consistent in terms and tone.** The same thing has the same name
everywhere (not "folder" here and "collection" there); the voice is
consistent across the product (see voice-and-tone, style-guides).
Inconsistent terminology makes users wonder if two things are
different.
## Boundaries
- UX writing serves the task and the moment; match the tone to the user's
state (calm in errors, celebratory in success; see voice-and-tone).
Humor in the wrong moment (a joke during a failed payment) breaks trust.
- Words cannot fix a broken flow or bad IA; if a screen needs a paragraph
to explain itself, the design or structure is the problem (see
information-architecture, interaction-design).
- Localization and accessibility constrain copy (length varies by
language, screen readers read labels literally); write for translation
and for assistive tech (see accessible-forms, aria-usage).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!