Consistency: Where System Feel Comes From
Good-looking sites sit on a set of design variables. Open this site's real CSS: why control height, radius, and color stay one tier sitewide — change once, everywhere updates
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Consistency: Where System Feel Comes From”?
Good-looking sites sit on a set of design variables. Open this site's real CSS: why control height, radius, and color stay one tier sitewide — change once, everywhere updates
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.
The mismatched feel has concrete causes: this button is 36 tall, that one 40; this card radius 8, that one 16; rose a shade deeper here, lighter there. Each was written ad hoc — fine alone, exposed when stacked. The fix is to fold those "ad-hoc numbers" into variables: set tokens first (primary, radius, control height, spacing steps), and every style reads from tokens. Fewer one-off decisions — the UI starts looking like one family.
Consistency sounds like fussiness; it buys real money. About Face 4 cites Nielsen's ledger: unified UI standards raise output and cut errors through predictability — rules learned on one page still work on the next, so learning cost and training spend drop. Apple and Microsoft happily let third-party apps look like their systems so users never have to relearn.
| With consistency, users gain | Without it, users pay |
|---|---|
| Buttons look like this, behave like that — you can predict with eyes closed | Every new page means probing from scratch |
| Learn once, works sitewide | "Last page, Save was top-right…" |
| UI fades into the background; attention stays on content | Differences keep yanking attention onto the chrome |
The same book says the hard part up front: standards cover the grammar of look and feel, not deeper logic. Treating standards as a cure-all is as wrong as thinking a style guide writes a great novel. So this lesson teaches setting variables for UI — not locking creativity.
This isn't a classroom fiction. The source of this site's course list page learn.html has these two variables — original comments included:
On the site you're reading, those five top-bar buttons are governed by these two variables: no one may bring their own size — all read 36px height and 10px radius. Want a sitewide restyle someday? Change these two lines.
Notice what just happened: you changed one variable, and the button, card, input, avatar, and modal moved together. Style is what variables are set to; system feel is that the variables exist. Values are debatable — variables must come first.
Once tokens are set, the remaining work is catching drift. The settings page below looks normal at a glance — it hides five inconsistencies of the kind AI-generated UIs ship every day. Tap each one you find.
About Face 4 puts the consistency test in two lines: every element needs a sufficient reason to exist, and every difference needs a sufficient reason too. A Delete button redder than the rest has a solid reason: different behavior should look different — identical looks with different jobs is what traps people. Flip it: two peer cards with radius 8 and 16, and nobody can say why — that's drift to fold in. The book also offers a handy lever: rather than add new elements, let one element do more jobs; fewer elements make consistency easier to keep.
What you learn here should become a paragraph at the top of any Prompt where you ask AI to build UI. The variable table below is ready to use — change values for your product. The key is that every decision has a source, so AI never gets to invent numbers for you.
This table governs "new UI from today." If the project has been running and styles already diverge, a variable table alone isn't enough — you have to pull scattered implementations back in first. That's surgery; the steps are in Vibe Coding · Style Convergence: Don't Ship Eight CSS Kits for One Button: how to inventory debt, merge in batches, and which differences to keep.
System feel comes from shared variables: set tokens first (primary, radius, control height); styles read from tokens — the cobbled-together feel fades.
Fastest consistency check: put two screenshots side by side; watch buttons, radius, and primary depth for drift.
When AI builds UI, hand over the variable table first: put primary, radius, and control height in the Prompt before it starts — consistency jumps.
The two-line test: every element needs a reason; every difference needs a reason. Keep Delete's red; fold in radii you can't explain.
Sources: Original to Xiaoshan Academy's Taste Engineering series; consistency, the value of standards, and "differences need reasons" adapted from About Face 4: The Essentials of Interaction Design, Chapter 17 (Alan Cooper et al.).
Turn the feeling in “Fine alone, cobbled-together as a whole” into a judgment
“The mismatched feel has concrete causes: this button is 36 tall, that one 40;” 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 “Consistency sounds like fussiness;” 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 “Sources: Original to Xiaoshan Academy's Taste Engineering series;” 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 “Fine alone, cobbled-together as a whole” to “What consistency buys you”
“Fine alone, cobbled-together as a whole” grounds the problem in “The mismatched feel has concrete causes: this button is 36 tall, that one 40; this card radius 8, that one 16; rose a shade deeper here, lighter there. Each was written ad hoc — fine alone, exposed when stacked…”. “What consistency buys you” then moves it toward “Consistency sounds like fussiness; it buys real money. About Face 4 cites Nielsen's ledger: unified UI standards raise output and cut errors through predictability — rules learned on one page still work on the…”. 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?
- “Fine alone, cobbled-together as a whole”: The mismatched feel has concrete causes: this button is 36 tall, that one 40; this card radius 8, that one 16; rose a shade deeper here, lighter there. Each was written ad hoc — fine alone, exposed when stacked…
- “What consistency buys you”: Consistency sounds like fussiness; it buys real money. About Face 4 cites Nielsen's ledger: unified UI standards raise output and cut errors through predictability — rules learned on one page still work on the…
- “The closing point”: About Face 4 puts the consistency test in two lines: every element needs a sufficient reason to exist, and every difference needs a sufficient reason too . A Delete button redder than the rest has a solid reaso…
The final “The closing point” brings the discussion to “About Face 4 puts the consistency test in two lines: every element needs a sufficient reason to exist, and every difference needs a sufficient reason too . A Delete button redder than the rest has a solid reaso…”. 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.