(remove filler, avoid repetition, be specific, lead with the
why — detailed below).
When reviewing copy across multiple screens or files, flag terminology inconsistencies and
suggest word list entries for new, missing or ambiguous terms.
Step 4: Deliver changes
Provide specific rewrites inline — show the original, then the rewrite, with a brief
rationale tied to the voice and principles. Prioritise changes that confuse or block users
before polish. The user should be able to review the changes and approve or reject them.
Voice and tone
Voice vs. tone
Voice
is the consistent personality of the product — the 3–4 qualities that define how
it always sounds. These don't change.
Tone
is how the voice adapts to the situation. Think of each voice quality as a dial you
can turn up or down depending on the moment:
Celebrating a milestone? Turn up warmth, dial back brevity.
Reporting an error? Turn up clarity and helpfulness, dial back friendliness.
Onboarding a new user? Balance helpfulness with warmth.
Confirming a destructive action? Turn up direct, keep calm and concise.
No quality should ever be turned all the way off.
Applying tone: a practical method
Pick the 3–4 qualities that define the voice.
For the specific situation, decide which qualities need emphasis.
Place each quality on a spectrum from low to high emphasis.
Write with that balance.
Example
For an error where someone can't connect to the network, clarity and
helpfulness go way up — the person needs to know exactly what to do. Simplicity stays
moderate because they need the most important details. Friendliness dials back because getting them
unstuck is more important than sounding warm.
Voice should never override usefulness
Personality shines in moments where it can — welcome screens, milestones, empty states.
Don't force it into error messages or critical flows. If voice gets in the way of clarity,
clarity wins every time. This is especially true for error messages, destructive actions and
situations where the writing is articulating a problem.
Core principles
These four principles — Purpose, Anticipation, Context, Empathy — form a framework for
thinking about what to write, how to write it, and when. They apply through the lens of
your voice.
1. Purpose
Every screen, every message, every label exists to help someone do something or understand
something. Before writing, answer:
what is the single most important thing the person
needs to know right now?
Use information hierarchy to signal what matters most.
Headlines and buttons carry the
primary message. Supporting text fills in detail. People often read headers and buttons
first — if someone reads only those, they should understand the situation.
Know what to leave out.
If information doesn't serve the purpose of this moment, move
it elsewhere or cut it. When a screen is trying to do too much, go back to its purpose
and strip away everything that doesn't serve it.
Have a purpose for every screen in a flow.
Define the purpose of the entire flow and
each screen within it. This prevents redundant steps and keeps things brief.
Tell people the purpose — it's not a secret.
When introducing a feature, tell them
why it exists and why it matters to them using the voice and tone as appropriate
to the situation.
2. Anticipation
Think of the interface as a conversation. In any good conversation there's a natural back
and forth — listening, responding, anticipating what the other person needs to hear next.
After telling someone about a problem, tell them how to fix it.
After asking someone to do something, make it obvious how to do it.
After someone completes something, acknowledge it and point forward.
Lead with the "why".
Put the benefit or reason before the instruction. "To get
reservation updates, enter your phone number" is stronger than the reverse — the benefit
is front-loaded where it has the most impact.
3. Context
People use products in wildly different circumstances — on a busy train, mid-conversation,
one-handed, in a crisis, at 2am. The usage context shapes the writing
Think outside the app.
Consider the physical and emotional situation. Someone getting
a health alert needs calm clarity; someone mid-exercise needs ultra-brief text they can
read at a glance.
Match density to available attention.
Mid-task text should be ultra-brief. Setup flows
can afford a bit more. Bigger screens require brevity too, because text must be large for
people to see it from a distance.
Timing matters.
Show information when it's relevant, not before. Place instructions
where the person is looking — if they're focused on a camera viewfinder, overlay the
instruction near their focal point.
Write for the device.
Screen size, input method, and usage patterns differ across
devices and media. Describe gestures correctly — don't say "click" on a touch device. Consider
that phones and watches offer personalisation but demand brevity; shared screens like TVs
may be seen by multiple people.
4. Empathy
You're writing for everyone who might use this product — different abilities, languages,
cultures, levels of technical fluency, and emotional states.
Use plain, direct language.
Avoid jargon, idioms, and culturally specific references
that may not translate.
Design for accessibility from the start.
Labels, descriptions, and alt text aren't
afterthoughts — for some people, they're the entire experience. Every interactive element
and every meaningful visual needs a thoughtful text label (see patterns reference for
detailed guidance).
Avoid unnecessary references to gender, age, or ability.
Use inclusive, neutral
language.
Consider localisation.
Text expands and contracts across languages. Some languages
read right-to-left. Abbreviations work differently. Your UI needs to accommodate these
changes — design short copy, not compressed long copy.
Writing craft
These are the practical editing moves that tighten copy. Apply them after you've confirmed
the voice and tone are right.
Remove filler words
Interface text has no minimum word count. Every word must earn its place.
Adverbs and adjectives
"Simply enter your license plate" → "Enter your license
plate." Words like "simply," "quickly," "easily," "just" promise something about the
person's experience that you can't guarantee. However, a descriptive word that genuinely
clarifies behaviour earns its place: "Feed your pets automatically" tells you something
"Feed your pets" doesn't. The test: does the word add meaning, or is it filler?
Interjections
"Uh oh!", "Oops!", "Oh no!" in error messages can sound like you're
not taking the problem seriously. Cut them.
Pleasantries
"Sorry" and "please" can sound insincere in automated messages. Use
them only when they genuinely add warmth, not as padding.
Unnecessary punctuation
Exclamation marks should be rare. If everything is exciting,
nothing is. Reserve them for genuinely celebratory moments.
The test
read the sentence without the word. If the meaning is unchanged, remove it.
Avoid repetition
Saying the same thing twice in different words is filler. Combine overlapping ideas into one
clear statement.
"We're running late. Your delivery driver won't make it on time. They'll be there in 10
minutes." → "Delivery delayed 10 minutes. Check the app for your driver's location."
When headline and body say the same thing in different words, collapse them. Each element
on screen should add new information.
Be specific, not vague
Name the thing: "Can't open 'Quarterly Report.pdf'" not "Can't open this file."
Name the action: "Cancel Subscription" / "Keep Subscription" not "Yes" / "No."
Give real information: "Your card ending in 4242 was declined" not "There was a payment
error."
Lead with the why
Messaging is most effective when you tell people why the next step matters before telling
them what it is. Structure as: "To [benefit], [instruction]."
"To keep your streak, solve today's crossword" beats the reverse.
"To get reservation updates, enter your phone number" beats the reverse.
This small reordering front-loads the motivation and makes the instruction feel like a
reasonable ask instead of a demand.
Keep a word list
Decide what you call things and stick to it. If you call it an "alias" on one screen, don't
call it a "username" on another.
A word list is a simple table:
Use
/
Don't use
/
Definition
. It prevents
terminology drift and helps anyone working on the product write consistently. Button labels
are especially good word list entries — if "Next" advances through a flow, use "Next"
everywhere, not "Continue" on one screen and "Proceed" on another.
Start small. Add a word at a time. As the list grows, it becomes a resource that defines how
the product sounds. The list should be exist as part of the product's documentation and
updated as the product evolves.
Use possessive pronouns sparingly
"Favorites" conveys the same message as "Your Favorites" and is more succinct. If you do use
possessive pronouns, be consistent and try not to switch perspectives. Avoid "we" — it's
often unclear who "we" refers to, and in error messages ("We're having trouble loading this
content") it obscures what actually happened. "Unable to load content" is clearer.
Sweat the details
Correct spelling, grammar, and punctuation make a product feel polished and trustworthy.
Inconsistent capitalisation, stray punctuation, or typos erode confidence — especially in
moments where trust matters (payments, permissions, health data).
Adopt capitalisation rules that align with the voice, then apply them consistently. Title
case reads as formal; sentence case reads as casual. Choose a style for each UI element type
and use it throughout.
Write for the space available. Buttons, notification titles, tooltips, and labels all have
limited screen real estate. If copy needs to be short, write a short sentence — don't
compress a long one.
Build language patterns
Consistency builds familiarity. When the same type of situation always uses the same
structure, the product feels cohesive and intuitive. Define patterns for common moments —
how flows begin ("Get Started"), how they advance ("Next" or "Continue" — pick one), how
they end ("Done"). Return to these patterns every time.
The simplest test
Read your writing out loud. If it sounds like how you'd explain something to a friend —
clear, natural, no filler — it's probably good. If it sounds like a robot, verbose, inconsistant, a legal
document, or an essay, keep editing.
Patterns reference
For detailed guidance on specific interface patterns — alerts, errors, empty states,
onboarding flows, notifications, accessibility labels, destructive actions, buttons, and
instructional copy — see
references/patterns.md
.
Sources and further reading
This skill draws on:
Apple HIG: Writing
Apple HIG: Alerts
WWDC22:
Writing for Interfaces
— the PACE framework (Purpose, Anticipation, Context, Empathy)
WWDC24:
Add Personality to Your App Through UX Writing
— voice/tone exercises, the dial metaphor
WWDC25:
Make a Big Impact with Small Writing Changes
— filler words, repetition, lead with the why, word lists
WWDC19:
Writing Great Accessibility Labels
— context-driven labelling, verbosity as a deliberate choice
Apple Style Guide