Design systems that survive handover to the client's team

We have inherited enough abandoned design systems to recognise the failure mode. It is never bad design. It is a system that requires its original authors to extend, and so the client's team quietly stops using it — first with a one-off override, then a parallel component, then a second system nobody named.

Rule 1: the code is the system

Design tokens live in the repository and the Figma library consumes them, not the other way around. If a colour changes, it changes in one file and propagates to both. Systems where the design file is the source of truth drift within two sprints of handover, because production pressure always wins.

Rule 2: document the "when not to"

Every component page has a section on when to use something else. This is the part teams skip and the part that determines whether the system holds. A button component with no guidance on when a link is more appropriate produces interfaces full of buttons.

Rule 3: accessibility is in the component, not the guideline

Focus states, contrast, target sizes and keyboard behaviour belong inside the component where they cannot be forgotten. A guideline document asking engineers to remember ARIA attributes is a guideline document that will be violated by the second sprint after handover.

• Focus rings built in and not removable by prop
• Contrast validated in CI against the token set
• Minimum target sizes enforced by the component, not the layout
• Reduced-motion variants defined alongside every animation

Rule 4: hand over by overlapping

The last six weeks of the engagement, the client's engineers write the new components and we review them. It feels slower and it is the only handover method we have seen work. A system nobody on the receiving team has ever extended is a system they will replace within a year.