Design systems need boundaries

A design system provides a shared vocabulary for how an interface looks and behaves. It standardizes colors, spacing, typography, and interactive controls so our feature teams do not have to reinvent them on every screen.

Without clear boundaries, however, a design system quietly turns into a second product codebase. We start seeing domain-specific token names, feature flags, and bespoke components that only one team understands. The boundary that saves us from this is straightforward: the design system owns how the interface communicates, while our products own what a given state means.

Figma's Design systems 101 and 102 are useful primers for standing a system up. This chapter is about where that system should stop.

Leave product meaning out of interface states

A design system should own a small, cohesive set of communicative treatments: info, warning, error, and success. It defines their color contrast, visual emphasis, icons, and presentation primitives.

Product domains, by contrast, deal with business concepts: low, medium, high, and critical. Those terms belong entirely to the product. They should never leak into our design system as tokens like high-severity or critical-incident.

In our features, we map domain state onto that shared meaning:

low or medium severity -> info
high severity          -> warning
critical severity      -> error

This mapping keeps both layers free to evolve independently. A product team can change what constitutes a "high severity" event without touching the color vocabulary. Meanwhile, the design system team can adjust warning colors or contrast ratios without knowing every business rule that triggers a warning.

Names follow the same line. warning is a reusable interface decision. high-severity-incident is a feature wearing a token's clothes.

Keep components oblivious

The boundary slips most often when shared components start making product decisions. For example, an action button should not take a user object and decide whether that person has permission to perform the action. Eligibility is a product rule. The button should simply accept disabled={!canDelete} and communicate the resulting state clearly to the screen and assistive technology.

The feature decides the policy; the component renders the result. When deciding where a rule lives, we can ask whether it needs to communicate the same way across all our products. If it does, it belongs in the shared language. If it interprets one product's business state or workflow, it belongs in the feature.