Conventions: Don't Let AI Invent New Interactions
Users operate software through conventions — learn once, use everywhere. Spot which control is faking innovation, and which thing that looks like a button isn't one
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Conventions: Don't Let AI Invent New Interactions”?
Users operate software through conventions — learn once, use everywhere. Spot which control is faking innovation, and which thing that looks like a button isn't one
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
Chapter 13 of About Face 4 splits interfaces into three approaches: grown from the program's internals (implementation-centric), drawn to look like real objects (metaphor), and learned (conventions / idioms). Cooper's stance is blunt: modern GUIs mostly run on the third. Windows, scrollbars, dropdown menus, hyperlinks — none of them are intuitive; users learned them one by one.
His example is the mouse: nobody glances at a mouse and knows it drives the on-screen cursor — someone has to teach you, or you fiddle for half a minute. Once learned, you never forget. Scroll, double-click, drag-and-drop, pull-to-refresh, swipe-left-to-delete — same story: learn once, use everywhere.
Alan Cooper, About Face 4, Chapter 13.
For product people that's a free gift: the world's products already taught your users — reuse existing conventions and learning cost is zero. The snag is AI often ignores that favor. It stitches patterns from training data and invents a control nobody has ever learned.
While we're here, bury the second approach too. In the early GUI boom, credit went to "looking like the real thing": desktops drawn as desks, folders as folders, users reading pictures. Cooper doesn't buy it in Chapter 13: metaphor interfaces make users play connect-the-dots between icon and function. Simple features maybe; anything abstract can't be drawn. "Batch-rename 50 files" — what would you draw?
Worse, metaphor overstays. Once users know the basics, leather textures and page-flip animations stop helping and start dragging — they eat space, constrain interaction, and drag mechanical-era rules along. Apple admitted it: the leather calendar in iOS 6 was wiped clean by iOS 7.
So conventions win by traveling light: they don't ask you to guess — they ask you to learn, and learning is fast. Next, how this vocabulary is built.
Chapter 13 has an inverted pyramid explaining why conventions are easy to learn: the whole GUI interaction vocabulary sits in three layers — fewer and simpler as you go down. Tap each layer to see what it holds.
Users can carry this vocabulary from other products into yours via mental models: they assume your UI obeys the same rules as the ten thousand they've used. How lost they get when models mismatch was covered in the Psychology part — here's a jump card, no re-teaching.
Cross-chapter · Mental models: the map in the user's headUsers bring an old product's model to your UI — mismatch once, get lost once. Where models come from and how to fix mismatches: Psychology Lesson 7 covers it. Tap to jump.Below is an AI-generated cloud-drive settings page. Features work, the UI isn't ugly — but it hides three clever inventions, each breaking a well-learned convention. Tap them one by one; hits get a verdict.
Why does AI do this? Its training data mixes everything: real products, award-winning concepts, portfolio showpieces from design communities. Ask for "a settings page with design sense" and it blends patterns from several sources — grammatically fine, rule-wise fighting each other.
One thing it can never learn: what your users already know. Conventions live in user experience. AI sees how a control looks, not thirty years of teaching history. So this gate is yours: any control that needs a tiny hint line to explain how to use it deserves suspicion.
The second word comes from Norman's The Design of Everyday Things: affordance — how a thing looks tells you how to use it. Cooper sharpens it in Chapter 13: affordance is about what you think it can do, counted separately from what it actually does. A small round button by a door reads as a doorbell to everyone — even if pressing it does something else, its affordance is still doorbell.
Classic case: the door handle. A horizontal metal bar shouts "pull me" in shape and height — but the door pushes. The shop sticks a "Push" label on. Useless; people still pull. Signals the hand can read speak louder than words.
On screen it becomes a contract: draw a button and you promise it can be clicked, reacts when clicked, and does what the label says. Controls that break the deal Cooper calls bait-and-switch affordance.
He also calls out flat design: early UIs used shadow and depth to shout "press me"; flat style scraped that away. Visually clean — affordance took the hit. So clickable elements in flat UIs need stricter discipline: one color, one shape, reserved for things that click. No guest appearances.
Two membership centers below — same upgrade card, two drawings. Tap the one you think keeps the contract.
Affordance has a zero-cost test: send a screenshot to someone who's never used it, give 5 seconds, ask them to point at what's clickable. Every miss is an affordance accident. Especially useful on AI-generated UIs — AI never asked that question while drawing.
Easy wrong conclusion here: always copy existing interactions — innovate and die. Cooper's ruler is finer:
Alan Cooper, About Face 4: if users must relearn, the payoff must be visible to the naked eye.
Navigation, save, forms — users rehearse these hundreds of times a day in other products. Changing the pattern forces them to relearn walking, with no real payoff — use the most common patterns here. Spend the innovation budget on your core differentiator: the capability unique to your product, where no convention exists to copy. Nail it, and others copy you.
Measure one question with that ruler. AI added four "highlight designs" to a batch file manager. Which innovation spent the budget right?
One last cheat sheet. Users already know these conventions cold from other products — copying them is free usability. Check AI output against this list; the right column pastes straight into a prompt.
| Convention | Where users learned it | Default ask for AI |
|---|---|---|
| Pull to refresh | Every feed app | Refresh lists with pull-down — don't invent a floating refresh layer |
| Swipe left to delete | System Mail, WeChat chat lists | Delete list items with swipe-left or a clear button — don't hide it in long-press menus |
| Bottom tab bar | Mobile apps' standard slot | Primary nav as bottom tabs, icon + label, 3 to 5 items |
| Shopping cart | Thirty years of e-commerce teaching | Multi-select then checkout keeps the cart model — don't invent a new metaphor |
| Drag-and-drop upload | Cloud drives and email attachments | Upload areas support drag-and-drop and keep "click to choose files" |
| Ctrl / Cmd + Z | Desktop software's old rule | Editing features must support undo shortcuts |
| Blue underlined links | Web lesson one | Links keep recognizable style; single-click goes there |
| Magnifying-glass search | Browsers and every content app | Search entry = magnifier icon plus placeholder hint text |
| Red badge dots | Phone notification systems | Unread cues use badge counts — don't invent blinking markers |
Nothing in the table asks users to learn — that's the value. The learning budget you save, by the last section's ruler, goes to your core differentiator.
Interfaces run on conventions: scroll, double-click, drag-and-drop — none are intuitive; all are learned. Good conventions last a lifetime; the world's products already taught your users (Cooper, About Face 4, Chapter 13).
Affordance is a contract: how a control looks is what it must do. Drawing a button promises clickable and reactive; something that looks like a button but doesn't click burns credit for every control on the page.
Spend innovation where it cuts: navigation and basics use the most common patterns; innovation budget goes to the core differentiator. Significant change must offer significant advantage — novelty without payoff is just load.
Prompt line for AI: "Navigation, forms, and basic buttons always use the most common standard patterns — don't invent new interactions; clickable elements must look clickable." Four handles covered; next lesson goes into detail: how to pick the controls themselves.
Source: Original to Xiaoshan Academy's Interaction Engineering series; some interaction principles adapted from About Face 4: The Essentials of Interaction Design; affordance concept from Don Norman's The Design of Everyday Things.
Turn the feeling in “None of the interactions you use came free” into a judgment
“Chapter 13 of About Face 4 splits interfaces into three approaches: grown from the program's internals (implementation-centric), drawn to look like real objects (metaphor), and lea…” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “His example is the mouse: nobody glances at a mouse and knows it drives the on-screen cursor — someone has to teach you, or you fiddle for half a minute.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “Prompt line for AI: "Navigation, forms, and basic buttons always use the most common standard patterns — don't invent new interactions;” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “None of the interactions you use came free” to “Metaphor doesn't travel far”
“None of the interactions you use came free” grounds the problem in “Chapter 13 of About Face 4 splits interfaces into three approaches: grown from the program's internals (implementation-centric), drawn to look like real objects (metaphor), and learned (conventions / idioms). C…”. “Metaphor doesn't travel far” then moves it toward “While we're here, bury the second approach too. In the early GUI boom, credit went to "looking like the real thing": desktops drawn as desks, folders as folders, users reading pictures. Cooper doesn't buy it in…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “None of the interactions you use came free”: Chapter 13 of About Face 4 splits interfaces into three approaches: grown from the program's internals (implementation-centric), drawn to look like real objects (metaphor), and learned (conventions / idioms). C…
- “Metaphor doesn't travel far”: While we're here, bury the second approach too. In the early GUI boom, credit went to "looking like the real thing": desktops drawn as desks, folders as folders, users reading pictures. Cooper doesn't buy it in…
- “The closing point”: Users can carry this vocabulary from other products into yours via mental models: they assume your UI obeys the same rules as the ten thousand they've used. How lost they get when models mismatch was covered in…
The final “The closing point” brings the discussion to “Users can carry this vocabulary from other products into yours via mental models: they assume your UI obeys the same rules as the ten thousand they've used. How lost they get when models mismatch was covered in…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.