Ux writing
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill ux-writingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.0 KB, as published. Nobody here has run it
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
- 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).
- 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).
- 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.
- 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).
- 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.
- 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).