Support a one-off that deviates from the system

WHAT THIS TESTS Whether you can let a team move fast on a deviation while protecting the integrity and maintainability of the shared design system.

A GOOD ANSWER COVERS First, design components with sanctioned escape hatches so deviation does not require hacks. Expose CSS custom properties for themeable values, accept className and style overrides, and favor composition so consumers can wrap or slot custom content rather than monkey-patching internals. Second, contain the one-off. Build it in the consuming application's own code, not inside the shared library, so it cannot affect other consumers. If a brand-new component is needed, keep it local until proven. Third, govern it. Document the deviation as a tracked exception, set a review point, and decide later whether the pattern is common enough to promote into the system properly or should be removed. This keeps the core stable while giving the team room.

COMMON WRONG ANSWERS Forking a core component into the shared library splits maintenance and confuses consumers. Overriding with !important fights the cascade and creates fragile, unpredictable styles. Letting bespoke styles live in the shared package pollutes every consumer. Saying no outright pushes teams to copy-paste and diverge anyway.

LIKELY FOLLOW-UPS When do you promote a one-off into the system? When multiple teams need it and it is stable. How do escape hatches avoid abuse? Keep them intentional and documented, not a free-for-all. How do you find drift later? Audit usage of overrides.

ONE CONCRETE EXAMPLE A marketing team needs a button with a gradient the system does not support. Instead of forking the Button, they pass a custom-property override the Button already exposes for its background, scoped to the marketing page. The deviation lives entirely in the marketing app, is logged as an exception, and is revisited next quarter; if other teams want gradients, it becomes a real system variant, otherwise it is removed with the campaign.