Skip to main content

ux-writing

Interface copy that works — voice/tone, the PACE framework, alert anatomy, naming features, empty states, error messages, and the small-word edits that measurably improve UX. Distilled from Apple's writing sessions (2017–2026). Use when writing or reviewing any user-facing text — labels, alerts, onboarding, notifications, empty states, paywalls — or naming a feature.

インストールへ移動

ソース情報

リポジトリ
rshankras/claude-code-apple-skills
ソースの最終更新活動
2026年7月16日 14:28
検出された SKILL.md の言語
英語
スター
753
フォーク
71

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
ux-writing
description
Interface copy that works — voice/tone, the PACE framework, alert anatomy, naming features, empty states, error messages, and the small-word edits that measurably improve UX. Distilled from Apple's writing sessions (2017–2026). Use when writing or reviewing any user-facing text — labels, alerts, onboarding, notifications, empty states, paywalls — or naming a feature.
allowed-tools
["Read","Write","Edit","Glob","Grep"]
last_verified
2026-07-16T00:00:00.000Z
review_by
2027-06-22T00:00:00.000Z
# UX Writing Interface text is interface design. This skill covers writing it: the frameworks Apple's writers use, the anatomy of the hardest components (alerts, errors, empty states, names), and the mechanical edits that improve any screen's copy in minutes. ## When This Skill Activates - Writing or reviewing user-facing copy: labels, buttons, alerts, onboarding, notifications - Naming a new feature, tier, or setting - Error messages that frustrate, empty states that dead-end, permission prompts that get denied - Localization prep (copy that survives translation) ## The PACE framework (Writing for Interfaces) Run every screen's copy through four questions: - **Purpose** — what must this screen communicate? Headers and buttons should carry the screen alone; know what to leave out. Hierarchy in words mirrors hierarchy in layout. - **Anticipation** — what will the user ask or do next? Write for that ("What comes next?"). - **Context** — where is the user right now (quiet home vs. busy airport, mid-task vs. idle)? That decides how much to say. - **Empathy** — write for a person having a problem, not for the system reporting one. ## Voice vs. tone - **Finding voice**: describe the app as a person, cluster the personality adjectives, keep 2–3 as your voice attributes — constant across the app, while tone flexes per moment (more directness for high-stakes info, sparing warmth in celebrations). - The test that recurs in every Apple session: **read it aloud**. Does it sound like the best version of your app talking? - ❌ Jargon ("it can make people feel left out"); ❌ personality at the cost of usefulness. ## The four small edits (biggest impact per minute) 1. **Cut filler**: "easily," "quickly," "simply," "just" — ✅ "Enter your license plate to pay for parking" ❌ "Simply enter your license plate number to quickly pay for parking." 2. **Kill repetition** — merge redundant sentences: ❌ "We're running late. Your driver won't make it on time. They'll be there in 10 minutes." ✅ "Delivery delayed 10 minutes." 3. **Lead with the why** — benefit before action: ✅ "To get reservation updates, enter your phone number." Notifications too: ✅ "Keep your streak going by solving today's crossword." 4. **Keep a word list** — three columns: approved term · alternatives to avoid · definition (e.g. "alias — not handle/username/title — the player's in-game name, shown to others"). Reuse identical button labels ("Next") everywhere; consistency builds trust. ## Alert anatomy (Writing Great Alerts) First: should this be an alert at all? Alerts interrupt by design — reserve them for things the user must know *now*. - **Title**: the main point, one sentence or less. **Message**: only if needed. - **The scannability test**: title + buttons alone must convey the situation. - ❌ Vague hedging ("You may need to…") — name the file, name the fix. ## Naming features (Craft Clear Names, WWDC26) Judge every candidate on three criteria: it **belongs** (fits the app and its location), it **sets expectations** (readers predict what they'll get), it **works everywhere** (languages, markets, platforms). - Process: **Think / Feel / Do** — what should the audience think, feel, and do? Group the answers into themes; name from the themes; test candidates in natural sentences ("just search for ___"). - ✅ Industry-standard words in high-stakes domains: "Balance," not "Spending Power." - ✅ Compounds are fine when the parts self-explain ("AutoMix"); emotional names win where the moment is emotional ("Memories"). - ❌ Implementation jargon — describe the outcome, not the mechanism. ## Empty states, permissions, localization - **Empty states**: never dead-end — say what will appear and how, ideally with example input. - **Permission prompts**: explain value first, ask at the contextually right moment (mechanics in `generators/permission-priming`). - **Localization**: plain language over idiom/humor; leave layout room and accessibility text for every element. ## Output Format Copy review table: ``` Location | Current | Problem (PACE / filler / vague button / jargon) | Rewrite ``` ordered by frequency-of-exposure (navigation labels before deep-screen prose). ## References - https://developer.apple.com/videos/play/wwdc2022/10037/ (Writing for interfaces) - https://developer.apple.com/videos/play/wwdc2024/10140/ (Add personality through UX writing) - https://developer.apple.com/videos/play/wwdc2025/404/ (Small writing changes) - https://developer.apple.com/videos/play/wwdc2026/290/ (Craft clear names) - https://developer.apple.com/videos/play/wwdc2017/813/ (Writing Great Alerts) - Related skills: `generators/permission-priming`, `generators/push-notifications` (notification copy), `app-store/app-description-writer` (store copy)
GitHubで見る