Design System API Review

Why it exists

Design systems succeed when they reduce decision fatigue and UI fragmentation across product teams. But a component that looks correct in Storybook can still fail at scale if its prop names are inconsistent, its behavior is unpredictable, or its surface area grows without governance. The API review exists because the cost of changing a public component interface rises exponentially after even one team ships production code against it. Catching interface issues at the pull request stage is orders of magnitude cheaper than running a deprecation campaign across thirty micro-frontends or mobile app releases.

The mental model

Think of a design system component as a library function that hundreds of engineers import into production code. The props are not mere configuration; they are a contract. Once you ship size="lg", you cannot rename it to scale="large" without a breaking change and a painful migration. The API review is the last moment you can freeze that contract and ask whether it will survive two years of product evolution without accumulating prop debt and confusion.

How it works

A small group of system owners and representative consumers review the component interface before it merges. They check naming conventions against the existing lexicon, evaluate whether new props duplicate existing ones, and assess if the prop types are too permissive. They also verify that the component does not expose implementation details, such as leaking a raw HTML attribute that couples consumers to the underlying DOM. The output is not a visual design critique but a checklist of contract decisions covering prop names, default values, event signatures, and token mappings.

When to use it

Use an API review when adding a new component, exposing a new prop on an existing component, or changing a default behavior that consumers rely on. It is also essential when crossing a platform boundary, such as aligning a React component with its Figma counterpart, to ensure the token names and variant structures stay in sync. Even a small change like renaming an event handler deserves scrutiny because it forces every consumer to update their code.

When not to use it

Do not use it for one-off components that live inside a single feature folder and are not exported by the system. Do not block urgent bug fixes behind an API review if the change is strictly internal and does not alter the public interface. If the review becomes a bottleneck that lasts days or requires scheduling a meeting two weeks out, it has morphed from governance into process theater and will lose engineering trust.

One canonical example

A team proposes a new Button prop called isDisabled to replace the existing disabled prop because they want boolean consistency with isLoading. During API review, someone notices that disabled is a standard HTML attribute and that isDisabled would break accessibility tools and confuse consumers. They keep disabled, add a dev-time warning for internal misuse, and document the rationale in the component decision log. Six months later, a mobile team wants the same pattern, and the written decision prevents a second debate and another breaking change.