Design systems usually start small and sensible. Then every new project adds a component that is almost, but not quite, like an existing one. A year later there are four card styles, three button sets and nobody is sure which to use.
A smaller system is often a stronger one.
Count what you have#
Start with an audit. Screenshot every button, card, input and modal in the product and group them by purpose. Most teams find several variations that exist only because someone did not know the original was there.
Questions for each component#
- What job does it do that no other component does?
- Is the difference from its neighbour intentional and documented?
- How many places use it?
- Would a variant of an existing component do the same job?
Prefer variants to new components#
A button with a clear set of variants, such as primary, secondary and quiet, in two or three sizes, covers almost every case. Defining those variants explicitly is better than adding a new button whenever a design needs something slightly different.
Design the content, not just the container#
Components fail when real content arrives: long titles, missing images, three lines of text where one was expected. Design each component with its edge cases, and document how it behaves when content is too long or absent.
Every component you add is one more thing someone has to choose between.
Keep design and code in step#
A component that exists in Figma but not in code, or the other way round, causes drift. Name them the same, review them together, and retire them together.
Make removing easy#
Celebrate deleting a component as much as adding one. A system that shrinks over time is usually one that is being used well.
