A design system brings together the parts of a digital product – visual styles, interface components, content patterns and code – with the guidance that explains when and how to use them. Its value lies less in the parts than in the decisions they carry: why an alert looks the way it does, what it should say and when it shouldn’t be used at all. Without that reasoning, a component library is a well-stocked cupboard that everyone raids differently.
Organisations have codified how they present themselves for decades. The New York City Transit Authority’s 1970 graphics standards manual, produced by Massimo Vignelli and Bob Noorda at Unimark, set out how the subway’s signs should look and included an approved list of station names, so content was in the system from the start. Web teams later built style guides and pattern libraries, and the modern design system took shape in the 2010s, when the parts became working code and the button a designer drew could be the same button a developer shipped.
Why it matters for content
Content is often the missing layer. Plenty of systems specify a button’s padding to the pixel and say nothing about what the button should say. Content specialists can define how components behave with real language, different lengths, errors and translations rather than squeezing copy into boxes designed around lorem ipsum. An error component needs more than red styling; it needs rules for naming the problem and helping someone recover. Voice and tone guidance, a word list of product names and component-level content rules mean that the many people who put words in front of users, from product managers to lawyers, start from the same decisions.
The system’s documentation is also content, with readers of its own. Designers and developers consult it in a hurry, usually halfway through a task. If the guidance is vague, buried or out of date, they guess, and consistency erodes one workaround at a time. Writing, structuring and maintaining that documentation is content work, and it often decides whether a system is adopted or admired and ignored.
Design systems multiply whatever they contain. Improve the wording of an error component and the improvement reaches every product that uses it; get it wrong and the mistake ships everywhere too. Nathan Curtis argued in 2016 that a design system is a product serving other products, with users, a roadmap and someone accountable for it, rather than a project that ends at launch. Contributions, ownership, versioning and deprecation prevent the library from becoming a museum of almost-identical buttons.
How AI changes the picture
Design systems are acquiring a second audience. Coding assistants and design tools increasingly read a system directly, through its code, its documentation and machine-readable formats such as design tokens, which record decisions about colour, type and spacing in a form different tools can share. A W3C community group published the first stable specification for them in 2025. When an assistant builds an interface from approved components, the system marks the boundaries of what it can produce.
That puts unusual weight on the guidance. A person reading “use sparingly” can ask a colleague what it means; a model will settle on its own interpretation. Rules about when not to use a component, what its content must include and which combinations don’t work need to be explicit and illustrated, because an assistant can assemble technically valid combinations that make no sense together. A team could generate trial empty-state messages against an approved pattern, then compare their meaning in the actual screen.
AI can also take on some of the upkeep: drafting documentation from code and design files, spotting where it has drifted from what’s shipped and presenting the same guidance differently to a junior designer and a senior developer. Generated documentation still needs review by people who know why the decisions were made. Lose the reasoning and what remains is a parts catalogue.
Questions people ask
- Is a style guide a design system?
Not on its own, though it may form part of one. A style guide sets conventions for language and presentation; a design system connects those conventions to the components, patterns and code that teams use directly.
- How does a design system relate to components and patterns?
Components are the reusable parts, such as buttons, alerts and cards. Patterns describe how to combine and adapt them for recurring tasks. The design system holds both, along with the principles, standards and documentation that explain them and the process for changing them.
- Does using a design system guarantee accessibility?
Accessible components help, but their combination, content and implementation still need testing. A well-built button doesn’t make an unclear or inaccessible booking journey work.
- Do smaller organisations need one?
Not a large one. A charity with a single website might need a short, maintained record of its components, key content patterns and word list, kept close to the code. If people keep solving the same problems in different ways, even a modest system will save time and confusion.
Learn more
- A Design System isn’t a Project. It’s a Product, Serving Products. – Nathan Curtis’s essay arguing that launch is where the work begins, and that a system needs product management, funding and a roadmap to survive.
- Content in, for, and of Design Systems – Michael Lawrence and Michael Haggerty-Villa’s piece for Indeed Design, separating three kinds of content work: the system’s own documentation, the content standards it sets for everyone else and the story that persuades people to use it.
- AI and Design Systems – Brad Frost’s 2024 account of how his team uses AI for component code, testing, accessibility review and documentation, including documentation that reshapes itself for each reader.