Skip to content

Principles

Six beliefs that shape every decision in prfct — from the lightness of a border to the name of a prop.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupéry

A design system is a set of decisions made once so they don't have to be made again. These principles explain how prfct makes them, and how to decide when the system doesn't have an answer yet.

1. Clarity over decoration

Every element must earn its place. Borders define structure, color signals meaning, motion explains change — nothing is there to look busy. When in doubt, remove it and see whether anything is lost.

2. Quiet by default, expressive with intent

Surfaces are neutral so that the few things that matter can speak. One primary action per view. One colored element per region. Expressiveness is a budget; prfct spends it where people need to look.

3. Precision is a feature

A 4px grid. Concentric corners. Control heights that align across components. Tabular figures in tables. Tracking tuned to the size of the text. People rarely notice precision, but they always feel its absence.

4. Accessible by construction

Contrast is solved, not reviewed. Focus is visible by default. Keyboard support comes from primitives that implement the WAI-ARIA patterns. Accessibility isn't a phase of the project — it's a property of the materials.

5. Responsive to people

Feedback within 100ms. Buttons keep their width and focus while loading. Errors appear where the problem is, in plain words. Motion honors reduced-motion preferences. The system adapts to people, not the other way around.

6. Open and yours

prfct is open code. You own every component the moment you install it: read it, change it, delete what you don't need. Tokens are data, exported in open formats. There is no lock-in, because there is nothing to lock.

Making new decisions

When you need something prfct doesn't have:

  1. Compose first. Most new components are compositions of existing ones.
  2. Use roles, not values. Pick the semantic token or scale step whose role fits.
  3. Match the neighbors. Heights, radii and spacing should align with the components beside it.
  4. Document the decision. A decision that isn't written down will be made differently next time.