Building a design system that teams actually use
Connect tokens, components, states and release rules to everyday product work instead of maintaining a library detached from implementation.
ecomvision editorial team
2 min
Published
Updated
Key takeaways
- 01Start with recurring journeys in the real product.
- 02Document behaviour and limits as well as appearance.
- 03Give design and code one understandable change process.
Inventory before invention
Collect real screens and identify repeated forms, tables, notices and navigation. Distinguish intentional differences from accidental inconsistency. Avoid designing dozens of variants when the product uses three.
Begin with an area the team changes regularly. A system proves its value in releases, not in the size of its documentation.
Name tokens by purpose
Error colours, primary text, surfaces and actions need semantic names. Apply the same approach to type, spacing and motion. Separate a raw palette from its use so theme and contrast changes remain manageable.
Allow justified exceptions rather than forcing every composition into the same pattern.
Treat components as contracts
Specify keyboard behaviour, loading, errors, long content and disabled actions. State which inputs a component accepts and who owns its state. Design and code should describe the same variants.
- When to use this component or choose another.
- Which states are required.
- An example with realistic content.
- Accessibility checks.
Own the changes
A proposed variant needs a problem and an example. The answer may be an extension, a composition or a local exception. Not every unusual screen belongs in a global API.
Document breaking changes and migration steps. Judge the system by reuse and reduced ambiguity, not by the number of components.