Skip to main content

Search rules

Search all UI Guides rules by name, category, or source

designCustom

Inconsistent Semantic Colors

SHOULD

SHOULD: Use semantic color tokens consistently - red/destructive for errors, green/success for confirmation, yellow/warning for caution, blue/info for information.

Use semantic colors consistently (error=red, success=green)

Bad

Good

Why it matters

This is our own rule, not an upstream citation — the Rams review has no bullet for it, and we previously mislabelled it as one. It is NOT the same rule as design-semantic-colors, which is about token naming (write `bg-destructive`, not `bg-red-600`, so themes can move). You can obey that one perfectly and still hand `bg-destructive` to the Save button. This rule is about the meaning a colour has already acquired: users read red as stop/danger and green as go/safe before they read the label, so an inverted pair does not merely confuse, it gets the destructive action clicked.

Fix the semantics of the mapping, then remember that colour is only ever the second signal — the label and the icon must say it too (see content-redundant-cues).

Built by Gleb Stroganov, design engineer at Evil Martians.

The rules come from other people's skills and guidelines — Vercel, Rauno Freiberg, @Ibelick, impeccable, Emil Kowalski, Tailwind, RAMS — each one credited on the Sources page. The work here is extraction and wiring: every rule is pulled into one corpus, given a good and a bad example you can operate, a MUST/SHOULD/NEVER rule an agent can paste, and a link back to where it came from.