Short answer: A design system is the shared set of design tokens, coded components and usage rules that a product team builds every screen from. A small team needs one once two or more people ship UI into the same product, or the same button exists in three versions. Before the screens settle, a token file and a few base components are enough.
Key takeaways
- Three layers: Tokens hold values, components turn them into code, guidelines say what goes where.
- Tokens now have a standard: The W3C Design Tokens Community Group published its first stable format, version 2025.10, on October 28, 2025.
- Start from a library: shadcn/ui or MUI already cover inputs, dialogs and menus.
- RTL belongs in the base: Logical CSS properties let one component serve Hebrew and English.
What a design system includes
Tokens are named values such as color.text.primary or space.4. The 2025.10 specification stores them in JSON with $value and $type fields, and lists Style Dictionary, Tokens Studio and Terrazzo as reference implementations, so one file can feed both Figma and the code.
Components are the coded buttons, inputs, tables and dialogs, with every state: hover, focus, error, loading. Guidelines are the short rules beside them: which button is primary, how an error message is phrased. Wording rules fit here, next to Hebrew microcopy for SaaS screens, and AI features add patterns of their own, covered in UX design for AI products.
Accessibility is cheapest at this layer: a dialog that handles focus correctly fixes every screen that opens it, which helps with IS 5568 accessibility rules in Israel.
When a small team needs one, and when it is premature
| Situation | What is enough |
|---|---|
| One designer, one developer, product changing weekly | A token file plus the components the library already provides |
| Several developers building screens in parallel | A shared component folder; check what exists before adding |
| The same component in three variants, or a second product on the same base | A documented system with an owner, versioning and a changelog |
Written too early, a system documents guesses. At the MVP stage, fix tokens and base components and extract patterns once they repeat, as with most software for startups.