Jelena Racković · · 4 min read · Design systems
Adding a design system to a product that already exists
Most design systems I have built did not start on a blank page. They started inside products that were already live, already used and already carrying years of decisions made by different people at different times. Introducing a system into that world is less like building a house and more like renovating one while the family still lives in it. It can be done well, and it rarely requires stopping anything.
Start with an honest look
The first step is always to look closely at what the product already uses. I collect every button, every colour, every spacing value and every pattern that appears on real screens, not in the design files, where things tend to look tidier than they are. The result is usually sobering: eleven shades of grey, four versions of the same card, and a modal that behaves differently on every page.
That inventory is not an accusation. It is a map. It shows where the product has been consistent without trying, where it has drifted, and which decisions are made again and again. Those recurring decisions are exactly what a system should take care of.
Sometimes the inventory reveals that there is no system at all. Sometimes it reveals that there was meant to be one, and that it exists mostly in name. Both situations are perfectly normal, and both can be worked out. The second simply needs a little more diplomacy.
Context comes before components
Before I name a single token, I want to understand the product around the interface: what kind of product it is, the market it competes in, who uses it and how often, and where it is heading in the next few years. A system for a public portal that must serve every citizen is built differently from one for a trading tool used by twenty specialists all day. Getting this wrong produces a technically elegant system that fits nobody’s reality.
Name the decisions, then the parts
Once the map is clear, I give the recurring decisions names. Colours become tokens with a purpose, such as a surface, a border or an alert, rather than a hexadecimal value someone once liked. Spacing becomes a scale. Type becomes a small set of roles. Naming by purpose matters, because it lets the product change its look later without anyone hunting through hundreds of screens.
Then come the components, starting with the parts that repeat most often. In an existing product that usually means buttons, form fields, tables and cards. A handful of well-made shared components replaces dozens of local variations, and the effect is visible within weeks.
Replace gradually, alongside the work
The new parts do not arrive in one big release. They replace the old ones gradually, screen by screen, alongside the development that is already planned. A team touching a page for a new feature takes the shared components with them. Nobody stops; the product simply becomes more consistent with every sprint.
This rhythm also keeps everyone on board. Developers see that the system makes their work faster rather than adding a layer of rules. Product owners see consistency improve without a freeze. And the system earns its place by being useful, which is the only way a system ever really earns it.
Where it ends up
After a few months, design and code share a single source of truth. New screens are quicker to build than the last ones, because most of what they need already exists. The old variations fade out rather than being torn out. And the product, which a few months earlier looked like the work of several different companies, finally looks like itself.
The lesson I keep relearning is that a design system does not need a fresh start. It needs patience, a clear map and the willingness to improve something that people are already relying on, without ever asking them to stop.
Is your design system starting to fade?
I’d like to hear about it →