Guidelines must say when not to use the component

What it is

A write-up that only lists what a component can do — submit, navigate, open a menu — lets the legal set expand without bound. Guidelines have to mark when not to use: a button is not navigation, a link is not a form submit, a menu item is not an in-page filter. That negative space belongs to the interface contract the way required props do. It is not a polite addendum.

The demand is that exclusion rules live inside usage itself, not that anti-example screenshots hang on the doc site versus next to the code — that is a placement problem.

Why it happens

A positive example teaches one legal path. Readers analogize: buttons are clickable, so every clickable thing becomes a button. The product then fills with links that look like buttons and menu items that look like links; keyboard expectations, roles, and crawlers follow the wrong object. Exclusion rules cut neighboring duties apart: navigation is a link (new tab, copyable URL), submit is a button (no address), in-page action is a menu item (stay in context).

Negative space also blocks a use forced in for the page in front of you. Without “do not use a button as a chip,” filter chips become a row of primary buttons. A contract missing exclusions silently permits every analogy not yet banned. Required props constrain the shape of values; exclusion rules constrain the situation in which this component is chosen. Together they are an executable API.

Where it stops holding

Exclusion rules for platform-native controls are already written by the system (the share sheet is not a settings page); product guidelines should point, not recopy. An experimental component may ship with positives only during exploration, but the moment it enters a stable channel the exclusions must land, or exploratory analogies freeze into convention. A pair that is meant to look alike and overlap on purpose (two emphasis levels of button) will have a short exclusion list; the work is degree, not mutual exclusion. An accessibility substitute (a visually hidden button for the screen reader) appears to break “one primary per region,” but it is a channel compensation and must be written as a legal exception, not passed on by word of mouth.

Applying it

• Split every stable component’s usage page into “use for / do not use for.” The do-not side names the neighbor and the replacement.
• Put exclusions where types or lint can see them (forbid wrapping Button around a fake link when href exists). Do not leave them in prose only.
• In review, ask first whether the new call site falls on the do-not side. If it does, pick another component; do not add a variant that legalizes the misuse.
• How to check: take ten recent call sites that used a button for navigation or a link for submit. The do-not side should reject them outright. If it cannot, negative space is not yet a contract.

Related

• Same group: R1.04.2 Counterexamples prevent misuse better than canonical examples · R1.04.3 Without guidelines, each team invents its own usage
• Nearby: R1.12 Usage guidelines and anti-example docs · R1.08 Premature abstraction
• Search terms: negative usage guideline · when not to use · API negative space