WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Writing for interfaces

Writing for interfaces

WWDC 2022DesignAccessibility & Inclusion
Watch original video

Highlight

Apple’s UX Writer team shared their thinking framework when writing interface copy. Copy isn’t just filler text—it’s a core part of the product experience. An app without copywriting is like a city without road signs.

Core Content

A lot of app copywriting is added when the interface is almost finished. The button needs a label, the pop-up window needs a description, and the empty state needs a prompt. The text written in this way can often only explain the finalized interface and cannot participate in the design.

The point of this session is straightforward: interface copywriting is also part of the design. Apple’s UX Writer calls this doing design through the lens of language. They give a writing framework: Purpose, Anticipation, Context, Empathy, which together are PACE.

This is not an API session and there are no official code snippets. An executable copywriting checklist is used below in place of code. It does the same thing as code: turns abstract principles into rules that can be verified step by step on every interface.

Interface copy review
- Purpose: What is the most important thing on this screen? Do the title and primary button say it first?
- Anticipation: When users read this, what are they most likely to want to know next?
- Context: In what situation does the user see this copy? Are they interrupted or in a hurry?
- Empathy: Can this copy be understood by users with different languages, abilities, and backgrounds?

Key points:

  • PurposeRequires defining the purpose of the screen before deciding which text to retain. -AnticipationThink of the app’s copywriting as a conversation and answer the user’s next questions in advance. -ContextThe copywriting is required to match the timing of appearance, device status and user attention. -EmpathyCopywriters are asked to take care of localization, accessibility, and inclusive expression.

Detailed Content

Purpose: Each screen only undertakes one main task

(03:12) Purpose is the reason the screen exists. Apple uses the name and avatar sharing guide page of Messages as an example: the title directly says “Share Your Name and Photo with Friends”, and the button says “Choose Name and Photo”. Even if the user only scans the title and buttons, they will know what the screen is about.

This brings about a practical writing method: write the title and main button first, and then write the main text. Because the user does not necessarily read the entire screen in sequence. Titles and buttons carry the heaviest weight of the information hierarchy.

Purpose checklist
1. Write a one-sentence purpose for this screen.
2. Check whether the title expresses this purpose.
3. Check whether the primary button expresses the next action.
4. Delete, move, or defer explanations unrelated to the current purpose.

Key points:

  • Line 1 condenses the design problem into a single goal, preventing one screen from explaining too many things at once.
  • Line 2 checks whether the information the user sees at first glance is useful.
  • Line 3 checks whether the button can express an action independently.
  • Line 4 handles redundant information. Apple deleted too many reasons in the iPhone temperature warning example.

(04:13) The counterexample of the temperature warning has too much content: maybe in the sun, maybe using too many apps, and making emergency calls. The final version retained only the title “Temperature,” the sentence “iPhone needs to cool down before you can use it” and the “Emergency” button. The picture already conveys the high temperature, so there is no need to repeat the text.

(05:59) Multi-step processes should also be handled in this way. Each step in the Apple Cash family sharing setup has a different purpose: it explains who can use Apple Cash, then it requires identity verification, and then it explains that activation may take a few minutes and will send a notification. Each screen only answers questions for the current step.

Anticipation: Treat interface copywriting as dialogue

(07:40) Anticipation is anticipating what the user will ask at this moment. In the alarm clock example of Clock App, when users temporarily change the alarm clock on weekends, what they are most concerned about is “only change the alarm clock for tomorrow, or change the entire weekend plan.” The action sheet directly asks “Would you like to apply this change to all weekends in this schedule?”, and the first option is “Change Next Alarm Only”.

This example illustrates that copywriting is more than just explaining what a button does. It needs to predict the most common intentions of users and clearly explain the default path.

Anticipation checklist
1. What did the user just do?
2. What is the user most likely worried about now?
3. What actions can the user take next?
4. Is the most common action the easiest to understand?

Key points:

  • Line 1 records the previous action that triggered the copywriting.
  • Line 2 shifts the copy from a system perspective to a user perspective.
  • Line 3 of the confirmation interface gives optional actions.
  • Line 4 checks whether the default option matches the user’s true intent at the moment.

(09:06) Apple also distinguishes between voice and tone. An app should have a steady sound, but the tone can change depending on the scene. When the Apple Watch detects a fall, it uses “It looks like you’ve taken a hard fall” and “I’m okay” to keep calm; when the Activity records a Move streak, the tone can be celebratory, so an exclamation mark is used.

(10:31) When writing, keep asking “What comes next?” The Breathe App starts by saying “Be still, and bring your attention to your breath,” followed by “Now inhale…” and “And exhale.” Copy, visuals and touch come together to answer the question “How do I get started?”

Context: The same sentence must be put back into use scene judgment

(11:47) Context requires thinking about the environment outside the App first. Is the user in a quiet home or at the airport? Are you walking, driving, cooking, or able to give your full attention to a screen?

The Apple Watch exercise reminder example is typical. The device detected that the user was walking outdoors but no workout was recorded. At this time, the user is exercising and is not suitable for reading long copy, so the interface only provides a big button: “Record Outdoor Walk”. After the exercise is over, the user’s attention becomes more focused, and the interface can display distance, pace, and active calories.

Context checklist
1. When the copy appears, is the user doing something else?
2. Is this a reminder, confirmation, error, or empty state?
3. If users only read the buttons, can they understand the outcome?
4. If this is an error, does the copy provide a path to fix it?

Key points:

  • Line 1 determines copy length and information density.
  • Line 2 distinguishes different interface types. Alert, error and empty status cannot use the same tone.
  • Line 3 from Subscription Cancel Example: Buttons can’t just say Yes and No.
  • Line 4 from the billing problem example: the error message is to give the next step.

(12:56) Alert is an interruption. When the Weather App requests location permission, a popup appears when the app is opened and explains that the location will be used for local weather and related notifications, so it is contextual.

(13:44) Destructive operations need to be more specific. The alert title for removing a device is “Remove iPhone?” and the buttons are “Remove” and “Cancel”. Counter-examples for canceling subscriptions only include “Confirm Cancellation”, “Cancel” and “Confirm”. It is difficult for users to determine which button will actually end the subscription. After changing to “Cancel Platinum Subscription?”, “Cancel Subscription” and “Keep Subscription”, you can make decisions just by looking at the buttons.

(15:29) The error message is the same. Counterexamples “Oops! you can’t do that” plus an error code and “Please try again” do not tell the user what happened. The better version has a title that says there is a billing problem, a text that says to add a new payment method, and the main button is simply “Add Payment Method.”

(16:38) Empty status can educate users. The restaurant app’s “Nothing strikes your fancy?” has a playful tone, but the idiom can be difficult to translate and doesn’t explain how the content appears. Apple Podcasts’ “No Saved Episodes” and “Save episodes you want to listen to later, and they’ll show up here” are clearer.

Empathy: Writing for Different Languages, Abilities, and Backgrounds

(18:02) Empathy is written for everyone. Apple recommends using simple, plain language and being careful with idioms and humor, as they may not translate and may exclude some users.

Localization is the core issue here. When English is changed to Thai, Dutch or Hebrew, the length, vertical space and reading direction will change. Not all languages ​​have single-letter abbreviations for weekdays in the calendar: Catalan uses two letters, and Arabic does not abbreviate them.

Empathy checklist
1. Does this sentence depend on idioms, slang, or internal terminology?
2. Can the layout still accommodate the copy after it becomes longer?
3. Is the interface order still clear in right-to-left languages?
4. When VoiceOver reads this content, does the user get enough information?
5. Are there unnecessary gender, identity, or cultural assumptions?

Key points:

  • Line 1 Reduce translation and comprehension costs.
  • Line 2 reminds the design to allow for text lengthening or line wrapping.
  • Line 3 covers right-to-left language scenarios such as Hebrew, Arabic, etc.
  • Line 4 writes the accessibility label as if it were a complete experience.
  • Line 5 avoids excluding users with unnecessary identity assumptions.

(20:10) Accessible copywriting must also be designed. Users using VoiceOver may rely entirely on element tags to understand the app. Apple takes Memoji Stickers as an example: descriptions include not just body movements, but also intentions and scenes, such as “as if sharing a secret,” meditating, nervous person biting fingernails. Also use “person” to avoid specifying gender unnecessarily.

The last step: read it out

(22:47) If you can’t find the right word, Apple’s final tip is to read it aloud. Reading it out can check whether the copy sounds like everyday conversation, and can also detect repetitions, grammatical errors and typos.

This advice is very practical. Interface copywriting is usually very short, and problems in short sentences are not easily exposed in the design draft. When read aloud, sentences that are awkward, too long, and look like system logs will be more obvious.

Core Takeaways

  • What to do: Write a Purpose line for each onboarding page. Why it’s worth doing: Session repeatedly emphasizes that each screen must have a clear purpose, and titles and buttons must first convey this purpose. How ​​to start: Add a column “screen purpose” next to the design draft. Write the purpose first, then the title, text and buttons.

  • What to do: Rewrite the destructive alert in the App. Why it’s worth doing: The unsubscription example illustrates that vague “Cancel”, “Confirm”, “Yes” and “No” will make users unable to judge the consequences. How ​​to start: Change the title to specific objects and actions, and change the buttons to words such as “Delete File” and “Keep File” that can independently express the results.

  • What to do: Add repair actions for error prompts. Why it’s worth doing: The billing problem example puts the error description and the “Add Payment Method” entry together, so the user doesn’t need to guess the next step. How ​​to start: List high-frequency errors and write “what went wrong”, “why it affects users” and “next button” as fixed check items.

  • What to do: Create a localized stress testing copybook. Why it’s worth doing: Session shows differences like Dutch getting longer, Thai requiring more vertical space, Hebrew going from right to left, etc. How ​​to get started: Check key flows with long strings, two-line buttons, RTL preview, and Dynamic Type.

  • What to do: Review the descriptive language in VoiceOver tags. Why it’s worth doing: Apple’s Memoji example puts action, intent, and context into descriptions and avoids unnecessary gender assumptions. How ​​to get started: Check the accessibility labels of icons, pictures, charts, and custom buttons one by one to make sure they can independently explain their meaning.

Comments

GitHub Issues · utterances