The UI Speaks: How Users Read Your Copy

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.

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.

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.

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.

One last combined quiz: button craft from this lesson plus the three elements above.

Source: Original to Xiaoshan Academy's Interaction Engineering series; some interaction principles adapted from About Face 4: The Essentials of Interaction Design.