What separates it from a style guide
A style guide describes. A design system is used. If the button in Figma and the button in the build are two separate artefacts that happen to look similar, you have a style guide and a drift problem.
The test is whether changing a token in one place changes it everywhere. If it does not, the system is documentation, not infrastructure.
| Style guide | Component library | Design system | |
|---|---|---|---|
| Contains | Rules and visual standards | Built, working elements | Both, plus usage decisions |
| Answers | How should this look | What can I use | What should I use, and when |
| Lives in | A document | Figma and code | Documentation plus code |
| Fails when | Nobody reads it | Nothing says which to pick | No owner maintains it |
The layers
- Tokens: the raw decisions, meaning colour values, the type scale, the spacing ramp, and radii
- Components: buttons, inputs, and cards, built only from tokens
- Patterns: recurring compositions such as a hero, a pricing table, or a form layout
- Documentation: what each piece is for, and when not to use it
Why it matters on a marketing site
Marketing sites accumulate pages faster than products accumulate screens. Without a system, the twentieth landing page is built by copying the nineteenth, and six near-identical button styles end up in production. With one, a new page is assembly rather than design.
Why it matters for B2B marketing teams
For a B2B marketing team the return on a design system is measured in launch speed. Without one, every new landing page is a design request. With one, a marketer assembles a page from existing sections and publishes the same afternoon.