The UI Speaks: How Users Read Your Copy
Picking the right control isn't enough—the UI still has to talk. The two words on a button and the one line in a dialog are the entire conversation between product and user. Microcopy is half of interaction: get it right and users don't have to think; get it wrong and even standard controls are wasted. AI has one trick for microcopy: slap "OK" on everything.
Count how many times you tapped "OK" today. It shows up in dialogs for delete, submit, quit, overwrite, clear—one word vouching for a hundred different consequences. Here's the problem: the button carries no answer; the answer lives in the body text, so users must finish the whole paragraph before they know what this tap does. OK/Cancel pairs are lazy—they push the reading cost onto the user.
The fix is to put the consequence on the button: swap "OK" for "Delete these 3," swap "Cancel" for "Keep them." Even if nobody reads a word of the body, a glance at the buttons is enough to answer safely. Cooper sets the same rule for action dialogs in About Face 4, Chapter 21: put a verb in the title. The title says what you're confirming; the buttons say what happens when you tap—neither side leaves the user guessing.
Alan Cooper, About Face 4, Chapter 21: verbs carry action and consequence; nouns and "Notice" carry nothing.
There's a test version of this rule: cover the dialog body and look only at the title and buttons—can you answer safely? If yes, the copy passes; if you have to peek back at the body, it's still a lazy OK/Cancel variant. Start with a few contrasts and feel what verb buttons do.
| Scenario | Lazy version | Consequence-carrying |
|---|---|---|
| Empty cart | OK / Cancel | Empty 12 items / Keep them |
| Leave editor | Yes / No | Save & exit / Discard changes |
| Unlink phone | Continue / Back | Unlink 138****2046 / Don't unlink |
Notice a side benefit of consequence-carrying buttons: quantity and object land on the button too (12 items, 138****2046)—a final check done for the user. Most mis-taps happen because "I thought I selected a different batch"; naming the object on the button dissolves that misunderstanding on the spot.
Beyond buttons, the second disaster zone is nouns. The UI says "Field user_mobile validation failed" or "Violates uniqueness constraint"—words no user knows, lifted straight from the database and the logs. Cooper digs out the root in Chapter 14: developers put the database's needs ahead of the user's, so the software ends up serving the CPU, and users feel like they're working for the software.
Chapter 14 also has a much-cited principle: the error may not be the program's fault, but it is the program's responsibility. A phone number short one digit, a duplicate username—those count as the user's "mistakes," but translating the error into words they understand and can fix is the program's job. Even menu names don't escape this: Cooper argues that "File" itself is an implementation-model word; an invoicing app's menu should be called "Invoices." Whatever users call their stuff, the UI should call it that too.
| System word | What it really means | Root cause |
|---|---|---|
| This action cannot be undone | Which action is "this action"? Say it | System-perspective deixis—users must recall the last step themselves |
| Error 422 | What was filled wrong, and how to fix it | HTTP status codes are developer logs (the case file from Lesson 2) |
| Session expired | Your login expired—sign in again | Session is an implementation-model word; the user's word is "login" |
AI is especially prone to this when writing UIs: it generates copy from the data structure, and the label becomes whatever the field is named. If you don't stop it, the database walks on stage and gives a speech. Next, rewrite a dialog by hand—three lines into human talk—and watch the mock change on the spot.
The delete-confirm dialog on the left is real AI output: title "Notice," vague body, buttons "OK / Cancel." On the right, tap "Plain talk" on each of the three lines; every rewrite updates the dialog live. When all three are done, run the cover-the-body test.
Define danger first: a dialog users will still tap through without understanding—that's dangerous. The cry-wolf experiment in the last lesson showed users spend less time on dialogs than it takes to finish one line; a fuzzy dialog is a knife left in a blind spot. Both dialogs below delete customer data—tap the one you'd dare hand a user.
Buttons done—now nouns. The five lines below are system-speak AI loves to dump on the UI. For each, pick the real human talk from two translations. Watch out: some options only dress up the system-speak; underneath they're still logs.
By now you may recall Lesson 2's error-copy rewriter: what happened, why, and what to do. Those three elements frame the skeleton of an error message; this lesson covers word choice inside that skeleton. Together they make a complete copy craft. We won't re-teach the three elements—the jump card is here.
Chapter cross-ref · The three states: loading, empty state, error stateThe error-message three elements (what happened, why, what to do) and full rewrites of three weak messages are covered in Lesson 2—tap here to jump.One last combined quiz: button craft from this lesson plus the three elements above.
Buttons carry consequences: swap "OK" for "Delete these 3," swap "Cancel" for "Keep them." Acceptance test: cover the body, look only at title and buttons—you can still answer safely.
Use the user's words: Session, field names, and error codes are implementation-model words—don't serve them to users (Cooper, About Face 4, Chapter 14). Translate until the user can act.
Errors are the program's responsibility: user input can be wrong; turning that wrong into words they understand and can fix is the program's job. Don't blame the user in the wording—the three-element skeleton is in Lesson 2.
How to brief AI: "Button copy names the action and the count; ban OK/Cancel pairs. UI copy must not show field names, error codes, Session, or other system words." UI details end here—next lesson starts translating these requirements for AI.
Source: Original to Xiaoshan Academy's Interaction Engineering series; some interaction principles adapted from About Face 4: The Essentials of Interaction Design.