The shared
agreement on good.
Principles are the rules that settle arguments before the meeting starts. A good principle is short enough to fit on a sticker, specific enough to decide a real tradeoff, and testable enough to apply at a Monday morning layout review.
01 — Why principles
The argument-settling layer.
Every design system gets to a point where two reasonable people prefer two incompatible patterns. Principles exist so the third person in the room can resolve the tie without it becoming a power play. They're the durable answer to "why this and not that."
Good principles are short, specific, and choose a side. They're different from values (what the team believes), strategy (where the product goes), and style guidelines (the visual register). Principles decide the next layout review.
02 — Canonical five
Five principles that show up everywhere good.
Pulled from the principle pages of IBM Carbon, Atlassian, Material, Polaris, and a dozen others. These five recur across mature systems because they reliably decide real tradeoffs. Adopt them, adapt them, or replace them with your own — but start with these as the baseline.
Clarity over cleverness
If two designs read the same to the system but one is obvious to the user, pick the obvious one. Cleverness is a tax users pay every day.
In action
- Name actions by what they do ("Save changes") not by where they go ("Submit")
- Prefer plain English over jargon — "Cancel" beats "Discard"
- If a tooltip is required to explain a button, the button is wrong
Consistency before novelty
A new pattern is a debt the rest of the system has to pay. Reach for the existing component first; create a new one only when nothing fits.
In action
- Same component, same behavior — across every product surface
- Reuse before redesign — extend a pattern over inventing one
- Document the canonical pattern; deprecate the rest
Restraint is a feature
Every additional element competes for attention. The mature interface is the one that says less, surfaces less, asks for less — and still does the job.
In action
- Default to the empty state — show only what the user needs
- One primary action per screen · everything else recedes
- Hide depth behind progressive disclosure, not behind density
Predictability earns trust
The user shouldn't have to guess what a click will do. Same trigger, same outcome — every time, every screen.
In action
- Same gesture means the same thing everywhere
- Errors are recoverable · destructive actions are confirmed
- Loading states are present whenever waiting > 200ms
Accessible by default
Reach is a baseline, not a feature. Every component ships keyboard-operable, contrast-correct, semantically labeled, on day one.
In action
- Contrast and focus rings are non-negotiable defaults
- Components ship with ARIA descriptions baked in
- No accessibility opt-in — only opt-out for known good cases
03 — How to write your own
Four tests every principle has to pass.
Borrowing principles works fine — most systems do. But if you write your own, run every candidate through these four tests. A principle that fails any test is decoration; cut it before it ships.
01
Make it specific to your product
Generic principles ("Be human", "Delight users") apply to everyone, decide nothing. Your principles should reference your audience, your domain, your tradeoffs.
02
Make it choose a side
A real principle has an opposite that's also reasonable. "Clarity over cleverness" is a principle because "cleverness over clarity" is a coherent alternative. "Be intuitive" isn't.
03
Make it short
Five to seven words, ideally three. If the principle can't fit on a sticker, it won't fit in a designer's head during a layout review.
04
Make it testable
Pair every principle with two or three concrete behaviors it implies. The principle isn't the headline — it's the heuristic that decides the next ten layout reviews.
The opposite test
Write the opposite of your principle. If the opposite is a coherent alternative someone could reasonably choose, you have a real principle. If the opposite is absurd, you have a slogan.
04 — Anti-patterns
Four ways principles become posters.
Every team eventually has principles. Most don't use them. These four patterns are why.
Generic principles
Avoid
"Be human" · "Delight users"Prefer
"Restraint is a feature" · "Predictability over surprise"Principles that apply to every product decide nothing. The test: write the opposite. If the opposite is absurd ("Be inhuman"), the principle is decoration. Useful principles can be argued against.
Too many principles
Avoid
12 principles on a posterPrefer
3–5 principles, memorized by the teamNobody remembers 12. They remember 4. Twelve principles means having none — the team can pull a citation for any decision they wanted to make anyway.
Aspirational, not operational
Avoid
"We're building the future of work"Prefer
"Two-tap reach for every primary action"Aspirational lines belong in marketing decks. Principles need to settle Monday morning arguments about whether a modal needs a confirm step.
Principles without examples
Avoid
"Clarity matters." · then silencePrefer
Principle · 3 in-action behaviors · 1 before/afterAn abstract principle won't make it into the design review. Pair every principle with concrete behaviors so the heuristic is visible the moment it applies.
Three to five principles. No more. No fewer.
Each principle chooses a side · the opposite is coherent.
Every principle ships with concrete behaviors to apply it.
Continue
Principles decide what good looks like. Voice decides how it sounds.
The text in a product carries as much brand as the visuals. Voice and tone is the foundation that decides how every button label, error message, and empty state reads.