Design System
A versioned library of components, tokens and patterns that encodes an organisation's interface decisions as reusable code.
A design system is architecture, not decoration. It is the mechanism by which accessibility, responsiveness, theming, keyboard behaviour and interaction consistency are solved once and inherited everywhere, rather than reimplemented per team at varying quality.
The leverage is largest on the properties that are easy to get wrong and expensive to audit. Accessible focus management, correct ARIA semantics, colour contrast, and touch target sizing are all decided in the component library. Fix one, and every product using it improves at the next version bump. That is a far better position than remediating twelve applications after an audit.
The recurring failure is treating it as a project. A design system ships, the team disperses, adoption stalls at 40%, product teams fork components to make deadlines, and within two years there are three divergent versions. It needs to be run as a product — with an owner, a roadmap, versioning, migration support and adoption measured.
The tension to manage explicitly is flexibility versus consistency. Too rigid, and teams fork to get what they need. Too flexible, and every consumer builds something different from the same primitives. The workable answer is a strong opinionated default with defined extension points, plus a route for contributing back what several teams needed.