sota-ux-writinglisted

# SOTA UX Writing & Product Copy ## Purpose Expert-level rules for the *words inside the product*: labels, buttons, errors, empty states, onboarding, notifications, and every other string a user reads while trying to get something done. The core thesis: **interface text is functional infrastructure, not decoration — a user reads it under task pressure, often in a second language, often through a screen reader, and every word either moves them forward or costs them a support ticket.** Boundaries: this skill owns the *language*. The UX *patterns* the language lives in (when to show an empty state, validation timing, dialog escalation) are `sota-frontend-design` rules/04; technical documentation is `sota-docs-workflow`; outward-facing marketing content is `sota-copywriting`; CLI-specific output contracts are `sota-cli-ux`. ## BUILD mode When writing or changing interface text: 1. **Write the unhappy paths first** — errors, empty states, and confirmations carry more consequence than the happy path (`rules/03`). 2. **Apply the plain-language spine** to every string: relevant, findable, understandable, actionable (ISO 24495-1) — front-load the point, one idea per sentence, common words (`rules/01`). 3. **Name things once.** Check the product glossary before introducing a term; never let the UI, docs, and API call the same concept different names (`rules/01` §4). 4. **Buttons are verbs with objects** ("Delete project", never "OK"/"Yes"), and every dialog stat