ux-writing

Name: ux-writing
Author: rshankras

548stars46forks

How to install ux-writing?

rshankras/claude-code-apple-skills/ux-writing

$npx -y skills add rshankras/claude-code-apple-skills --skill ux-writing

Installs into the current project.

Summary

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 —

Files · 1

View on GitHub

SKILL.md

1	# UX Writing
2
3	Interface text is interface design. This skill covers writing it: the frameworks Apple's
4	writers use, the anatomy of the hardest components (alerts, errors, empty states, names), and
5	the mechanical edits that improve any screen's copy in minutes.
6
7	## When This Skill Activates
8
9	- Writing or reviewing user-facing copy: labels, buttons, alerts, onboarding, notifications
10	- Naming a new feature, tier, or setting
11	- Error messages that frustrate, empty states that dead-end, permission prompts that get denied
12	- Localization prep (copy that survives translation)
13
14	## The PACE framework (Writing for Interfaces)
15
16	Run every screen's copy through four questions:
17
18	- Purpose — what must this screen communicate? Headers and buttons should carry the screen
19	alone; know what to leave out. Hierarchy in words mirrors hierarchy in layout.
20	- Anticipation — what will the user ask or do next? Write for that ("What comes next?").
21	- Context — where is the user right now (quiet home vs. busy airport, mid-task vs. idle)?
22	That decides how much to say.
23	- Empathy — write for a person having a problem, not for the system reporting one.
24
25	## Voice vs. tone
26
27	- Finding voice: describe the app as a person, cluster the personality adjectives, keep 2–3
28	as your voice attributes — constant across the app, while tone flexes per moment (more
29	directness for high-stakes info, sparing warmth in celebrations).
30	- The test that recurs in every Apple session: read it aloud. Does it sound like the best
31	version of your app talking?
32	- ❌ Jargon ("it can make people feel left out"); ❌ personality at the cost of usefulness.
33
34	## The four small edits (biggest impact per minute)
35
36	1. Cut filler: "easily," "quickly," "simply," "just" — ✅ "Enter your license plate to pay
37	for parking" ❌ "Simply enter your license plate number to quickly pay for parking."
38	2. Kill repetition — merge redundant sentences: ❌ "We're running late. Your driver won't
39	make it on time. They'll be there in 10 minutes." ✅ "Delivery delayed 10 minutes."
40	3. Lead with the why — benefit before action: ✅ "To get reservation updates, enter your
41	phone number." Notifications too: ✅ "Keep your streak going by solving today's crossword."
42	4. Keep a word list — three columns: approved term · alternatives to avoid · definition
43	(e.g. "alias — not handle/username/title — the player's in-game name, shown to others").
44	Reuse identical button labels ("Next") everywhere; consistency builds trust.
45
46	## Alert anatomy (Writing Great Alerts)
47
48	First: should this be an alert at all? Alerts interrupt by design — reserve them for things
49	the user must know now.
50
51	- Title: the main point, one sentence or less. Message: only if needed.
52	- The scannability test: title + buttons alone must convey the situation.
53	- ❌ Vague hedging ("You may need to…") — name the file, name the fix.
54
55	## Naming features (Craft Clear Names, WWDC26)
56
57	Judge every candidate on three criteria: it belongs (fits the app and its location), it
58	sets expectations (readers predict what they'll get), it works everywhere (languages,
59	markets, platforms).
60
61	- Process: Think / Feel / Do — what should the audience think, feel, and do? Group the
62	answers into themes; name from the themes; test candidates in natural sentences ("just
63	search for ___").
64	- ✅ Industry-standard words in high-stakes domains: "Balance," not "Spending Power."
65	- ✅ Compounds are fine when the parts self-explain ("AutoMix"); emotional names win where the
66	moment is emotional ("Memories").
67	- ❌ Implementation jargon — describe the outcome, not the mechanism.
68
69	## Empty states, permissions, localization
70
71	- Empty states: never dead-end — say what will appear and how, ideally with example input.
72	- Permission prompts: explain value first, ask at the contextually right moment (mechanics
73	in `generators/permission-priming`).
74	- Localization: plain language over idiom/humor; leave layout room and accessibility text
75	for every element.
76
77	## Output Format
78
79	Copy review table:
80
81	```
82	Location \| Current \| Problem (PACE / filler / vague button / jargon) \| Rewrite
83	```
84
85	ordered by frequency-of-exposure (navigation labels before deep-screen prose).
86
87	## References
88
89	- https://developer.apple.com/videos/play/wwdc2022/10037/ (Writing for interfaces)
90	- https://developer.apple.com/videos/play/wwdc2024/10140/ (Add personality through UX writing)
91	- https://developer.apple.com/videos/play/wwdc2025/404/ (Small writing

People who liked this also viewed

6 picks

Type

ux-writing

548stars46forks

View on GitHub

How to install ux-writing?

rshankras/claude-code-apple-skills/ux-writing

$npx -y skills add rshankras/claude-code-apple-skills --skill ux-writing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# UX Writing
2
3	Interface text is interface design. This skill covers writing it: the frameworks Apple's
4	writers use, the anatomy of the hardest components (alerts, errors, empty states, names), and
5	the mechanical edits that improve any screen's copy in minutes.
6
7	## When This Skill Activates
8
9	- Writing or reviewing user-facing copy: labels, buttons, alerts, onboarding, notifications
10	- Naming a new feature, tier, or setting
11	- Error messages that frustrate, empty states that dead-end, permission prompts that get denied
12	- Localization prep (copy that survives translation)
13
14	## The PACE framework (Writing for Interfaces)
15
16	Run every screen's copy through four questions:
17
18	- Purpose — what must this screen communicate? Headers and buttons should carry the screen
19	alone; know what to leave out. Hierarchy in words mirrors hierarchy in layout.
20	- Anticipation — what will the user ask or do next? Write for that ("What comes next?").
21	- Context — where is the user right now (quiet home vs. busy airport, mid-task vs. idle)?
22	That decides how much to say.
23	- Empathy — write for a person having a problem, not for the system reporting one.
24
25	## Voice vs. tone
26
27	- Finding voice: describe the app as a person, cluster the personality adjectives, keep 2–3
28	as your voice attributes — constant across the app, while tone flexes per moment (more
29	directness for high-stakes info, sparing warmth in celebrations).
30	- The test that recurs in every Apple session: read it aloud. Does it sound like the best
31	version of your app talking?
32	- ❌ Jargon ("it can make people feel left out"); ❌ personality at the cost of usefulness.
33
34	## The four small edits (biggest impact per minute)
35
36	1. Cut filler: "easily," "quickly," "simply," "just" — ✅ "Enter your license plate to pay
37	for parking" ❌ "Simply enter your license plate number to quickly pay for parking."
38	2. Kill repetition — merge redundant sentences: ❌ "We're running late. Your driver won't
39	make it on time. They'll be there in 10 minutes." ✅ "Delivery delayed 10 minutes."
40	3. Lead with the why — benefit before action: ✅ "To get reservation updates, enter your
41	phone number." Notifications too: ✅ "Keep your streak going by solving today's crossword."
42	4. Keep a word list — three columns: approved term · alternatives to avoid · definition
43	(e.g. "alias — not handle/username/title — the player's in-game name, shown to others").
44	Reuse identical button labels ("Next") everywhere; consistency builds trust.
45
46	## Alert anatomy (Writing Great Alerts)
47
48	First: should this be an alert at all? Alerts interrupt by design — reserve them for things
49	the user must know now.
50
51	- Title: the main point, one sentence or less. Message: only if needed.
52	- The scannability test: title + buttons alone must convey the situation.
53	- ❌ Vague hedging ("You may need to…") — name the file, name the fix.
54
55	## Naming features (Craft Clear Names, WWDC26)
56
57	Judge every candidate on three criteria: it belongs (fits the app and its location), it
58	sets expectations (readers predict what they'll get), it works everywhere (languages,
59	markets, platforms).
60
61	- Process: Think / Feel / Do — what should the audience think, feel, and do? Group the
62	answers into themes; name from the themes; test candidates in natural sentences ("just
63	search for ___").
64	- ✅ Industry-standard words in high-stakes domains: "Balance," not "Spending Power."
65	- ✅ Compounds are fine when the parts self-explain ("AutoMix"); emotional names win where the
66	moment is emotional ("Memories").
67	- ❌ Implementation jargon — describe the outcome, not the mechanism.
68
69	## Empty states, permissions, localization
70
71	- Empty states: never dead-end — say what will appear and how, ideally with example input.
72	- Permission prompts: explain value first, ask at the contextually right moment (mechanics
73	in `generators/permission-priming`).
74	- Localization: plain language over idiom/humor; leave layout room and accessibility text
75	for every element.
76
77	## Output Format
78
79	Copy review table:
80
81	```
82	Location \| Current \| Problem (PACE / filler / vague button / jargon) \| Rewrite
83	```
84
85	ordered by frequency-of-exposure (navigation labels before deep-screen prose).
86
87	## References
88
89	- https://developer.apple.com/videos/play/wwdc2022/10037/ (Writing for interfaces)
90	- https://developer.apple.com/videos/play/wwdc2024/10140/ (Add personality through UX writing)
91	- https://developer.apple.com/videos/play/wwdc2025/404/ (Small writing

People who liked this also viewed

6 picks

Type