Design principles

Five ideas do most of the work in Prism. When a decision is unclear, these are the tie-breakers.

1. Accessible by default

A component is not finished until it works with a keyboard, announces itself to a screen reader, and clears contrast at its smallest size. This is not a later pass. Focus rings, hit targets and reduced-motion fallbacks ship with the component, so a team using Prism gets them for free and has to work to remove them, not to add them.

2. One source, many skins

Every product in the family runs the same components. They look distinct because each remaps the brand ramp and a few signature tokens — not because anyone forked a button. If you find yourself overriding a component's internals to match a product, the fix belongs in a signature, not in the screen.

3. Tokens over values

Hard-coded hex codes and pixel values are how systems drift. Reach for a token. If the token you need does not exist, that is a signal to add one deliberately, where everyone can see it, rather than to inline a value that quietly becomes a fork.

4. Density is a setting

Compact, neutral and relaxed are the same components at three rhythms, driven by one attribute. A data-heavy admin screen and a roomy marketing surface can share a code path. Never rebuild a component to make it tighter.

5. Make the right thing the easy thing

Defaults matter more than options. The most common, most correct use of a component should require the least configuration. Edge cases are supported, but they should feel like edge cases — never the default path.

How to use these

Most review comments map back to one of the five. "Why is this a custom shade?" is principle 3. "This won't tab" is principle 1. Naming the principle turns a matter of taste into a shared rule, which is the entire point of a system.