When a team decides it needs a design system, the temptation is to start fresh: a new palette, a new set of components, a clean file. But the product already exists, with its own patterns, habits and code. A system that ignores them will struggle to be adopted.
There is also a practical reason. An inventory shows how much work the system can save, which helps make the case for the time it needs. A board covered in slightly different buttons is persuasive in a way a proposal is not.
Take an inventory
Go through the live product and collect every instance of the common elements: buttons, form fields, colours, type sizes, cards, icons, spacing. Screenshots pasted onto one large board are enough. The aim is to see everything side by side.
Include the code as well as the screens. Engineers can often list how many colour values, font sizes or button styles are defined in the codebase. The numbers are usually higher than anyone expected.
Let the duplicates speak
The inventory usually shows many near-identical versions of the same thing: several shades of the brand blue, a handful of button heights, different ways of showing an error. Each one was a reasonable local decision. Together they make the product feel inconsistent and cost time every time someone chooses between them.
For each group of duplicates, pick the version that should survive, or define a new one that replaces them all. Record the decision and the reason, so the same debate does not reopen next month.
Standardise the most used first
Rank what you found by how often it appears and how much the variations cause problems. Buttons, inputs, colour and type usually come first because they are everywhere. Rarely used components can wait until a project needs them.
Delivering these first components quickly matters. A system that shows useful results within weeks earns the trust and time it needs to grow. One that spends months on foundations before anything is usable often loses momentum.
Keep what works
Some existing patterns are good and familiar to customers. The system should adopt them rather than replace them for the sake of novelty. Changing what people already know has a cost, and it should be paid only when the new version is clearly better.
