Special Topic · Interaction Engineering: Make the Product Usable

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 FIRST

What 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

DECISION RULE

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.

TRY NEXT

Capture one before-and-after example that shows the quality bar without extra explanation.

WATCH FOR

Polish that improves the surface while leaving the user's uncertainty untouched.

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). 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.

"All idioms must be learned; good idioms need to be learned only once."
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.

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 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.

Three layers of vocabulary: why GUIs are learnable

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.

The inverted pyramid of interaction vocabulary Viewed 0 / 3
From the bottom up the vocabulary stacks richer — but the foundation is just a few actions
Tap any layer on the left. Read the pyramid bottom-up: the foundation is tiny, yet the building can go high — that's the structural reason GUIs are learnable.

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.
Hands-on · Three inventions hide in this settings page

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.

Find the controls faking innovation Found 0 / 3
Tap controls that feel wrong. Tapping a legit control still gets a reply
pan.example.com/settings
Account settingsCloud Drive Premium
Basic profile
Invention ①
Mist Watcher
mist@example.com
Not set
Not configured
Untitled
Page 1 / 3 · Swipe left for more fields
General
Notifications
Invention ② View membership benefitsDouble-click to open Annual plan · 208 days left
Invention ③ Save After click, the ring fills once = save success
Log out
Invention ① · Sideways-scrolling form: users can't learn it. Form convention is top-to-bottom: scroll, fill, submit — unchanged for thirty years. Horizontal paging stuffs required fields into dark cubbies; users think they're done, hit Save, and drown in errors. To save height, use collapse or groups — don't change direction.
Invention ② · A link that needs a double-click: users can't learn it. Underlined blue text — the Web contract is single-click to go. Double-click belongs to desktop-icon conventions. Mix the two rules and nobody guesses; you end up teaching with a tiny hint line. A control that needs a manual has already failed.
Invention ③ · Progress-ring Save button: users can't learn it. Save has the world's most common pattern: a solid button that says "Save." As a ring, users first think "what's loading?" then "can I even click this?" The control stops self-explaining — the invention threw affordance away.
All three inventions caught. Notice what they share: each looks clever alone, and fails by breaking rules users already know. One acceptance line for AI: "Navigation, forms, and basic buttons use the most common standard patterns — don't invent new interactions." Where to spend innovation: last section of this page.

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.

Affordance: controls must explain themselves

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.

If it looks like a button, it must click A/B duel
Tap a card to vote; verdict after you pick
Plan A
vip.example.com
Desktop clientCheck for updates
Current version v3.2.0, last checked today 09:41
You're up to date
The big blue pill looks most like a button — click does nothing. The real action "Check for updates" shrinks to small type up top
Plan B
vip.example.com
Desktop client
Current version v3.2.0, last checked today 09:41
You're up to date
Check for updates
Status sits honestly as gray text plus a dot; action gets a real button

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.

Spend innovation where it cuts

Easy wrong conclusion here: always copy existing interactions — innovate and die. Cooper's ruler is finer:

"Significant change must offer significant advantage."
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?

Four highlight designs — which one earns its keep? Single choice
Wrong answers still get explanations — keep going until you hit right
AReplace bottom nav with a press-and-hold radial pie menu
BUpload progress as a skeuomorphic water glass — full = done
CCore feature batch rename: change one rule, live-preview fifty filenames
DDouble-click a file card to favorite — no favorite button on the UI
Common-pattern list: copy these without apology

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.

ConventionWhere users learned itDefault ask for AI
Pull to refreshEvery feed appRefresh lists with pull-down — don't invent a floating refresh layer
Swipe left to deleteSystem Mail, WeChat chat listsDelete list items with swipe-left or a clear button — don't hide it in long-press menus
Bottom tab barMobile apps' standard slotPrimary nav as bottom tabs, icon + label, 3 to 5 items
Shopping cartThirty years of e-commerce teachingMulti-select then checkout keeps the cart model — don't invent a new metaphor
Drag-and-drop uploadCloud drives and email attachmentsUpload areas support drag-and-drop and keep "click to choose files"
Ctrl / Cmd + ZDesktop software's old ruleEditing features must support undo shortcuts
Blue underlined linksWeb lesson oneLinks keep recognizable style; single-click goes there
Magnifying-glass searchBrowsers and every content appSearch entry = magnifier icon plus placeholder hint text
Red badge dotsPhone notification systemsUnread 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.

Key Takeaways

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.

Mark as learned Your reading progress updates automatically
← PreviousNext →

Keep reading

The next useful article in the thread.

ARTICLE DISCUSSION

Leave one useful thought here.

Keep the idea that clicked, the question that stayed open, or a small note for the next learner.

Discussing Conventions: Don't Let AI Invent New Interactions Interaction Engineering: Make the Product Usable
3discussionsArticle discussion · synced with the Circle
View in the learning circle
AM
Asha MorganContent editor
INSIGHTField note

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.

ARTICLE DISCUSSION7 helpful
LH
Lin HarperIndie developer
INSIGHTInsight

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.

ARTICLE DISCUSSION5 helpful
KM
Kiki MooreProduct operations
QUESTIONQuestion

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.

ARTICLE DISCUSSION4 helpful