One of the most common promises we make when making an investment case for design systems is that they’ll reduce or completely eradicate duplication of effort.
“Look at all these different button instances we have! Once we have a design system, we can just create components once and use them anywhere” - goes the pitch.
The problem is that it’s not a promise design systems can, or indeed should, fulfill.
First off, it takes time to grow a design system’s coverage. The idea that a design system will answer every team’s need from the moment it comes into existence is clearly unrealistic, but somehow pervasive.
What’s more, removing duplication of effort entirely harms a design system’s usefulness.
Design systems exist to provide common solutions that are versatile enough to be applied in multiple contexts. To do that successfully, we first need to fully understand those contexts - and that means diverging before we converge.
When organisations treat duplication of effort as an intolerable and urgent problem to be rectified, it often leads to rushing - which can damage trust and slow adoption.
Ultimately, design systems are not replacing nothing. They’re replacing context-specific (if inefficiently created) solutions.
It doesn’t make sense for product teams to adopt design system components and patterns unless it matches or exceeds the quality of those that they’re already using. This can’t be achieved without taking the time to review context-specific elements before creating a centralised offering.
That's why I've come to see duplication of effort not as a sign of failure in design systems, but rather an essential part of their success. Treating it as such is what ultimately helps us remove needless waste from our workflows.