Mature design system problems

Adoption is a design system grail. You chase it, and the hardest work is the road to get there. It is paved with well-identified challenges: proving ROI, building up critical mass of available components, engaging product leads, enforcing a consistent engineering pattern, managing the existing debt etc...

But what happens once you've cleared them and your system has reached full adoption?

You might expect this, but every one of those proving ground issues will still apply after mass adoption, albeit with a twist.

ROI after adoption

Adoption changes the ROI debate. Speed is the initial return on the core investment, but once teams are used to it, they only see the constraints that enable this speed. The velocity becomes mundane.

What constitutes good ROI now? It depends on the business need that this new friction vexes. Keep the accelerating power of the system visible, even when constraints slow things down. "Yes, here the system is a constraint, but".

The "but" is important. A good way to highlight it is to keep publishing metrics, closely following the product teams' output. Estimating how much time they saved by using the system versus building from scratch, broadcasting those wins will always help.

Becoming mature was a victory, but it doesn't mean you should stop celebrating the next ones.

And sometimes you still need to build, to demonstrate you have not lost the system's ability to produce new components quickly. It will never stop, and you will always need to be relevant, because even though the bulk of the investment is past, the returns are expected to be forever.

Technical debt and component library management

Do you remember the things you've purposely left broken along the way? Because you have: there have been battles to pick, and each time debt was created. Debt will eventually slow you down.

You must now fix it by using the system. Which can be fairly annoying ("I told you not to do it, now you ask me to fix it") but that's also a thing mature and budding systems have in common: when they become an obstacle to the business, there is no way to "win" and no comfort.

But budding systems have the excuse of youth. Stakeholders will be more forgiving of inconsistencies then, but more concerned when their expensive, mature system is caught missing the mark.

A mature system is also easily bloated. In order to reach critical mass, you have likely built a component library (or several) that filled every single need your product UI ever had, thought it had, and maybe no longer has. That is the first source of bloat, and pruning it means digging through layers of product sediment.

Libraries are also rarely built from the get-go with their ultimate, best-ever technical architecture. That's often already tough enough to fix on a small library. But once your library has grown and spread across your entire product, that challenge worsens.

Now when you fix your mistakes, you have to make doubly sure the fix is not breaking anything. It sometimes means having to section off debt by deprecating components instead of migrating them all, which is just postponing the issue. That's the price of success: it is high maintenance...

So what do you do? You plan. You prioritise. You estimate. And you take it one step at a time. A design system is not a product, not something you buy, use and eventually dispose of. It is infrastructure, treat it as a long-term commitment.

Stakeholder expectations and trust

There is also a challenge of the human kind. The champions that helped make the design system a success are very likely to have moved on or moved up. They will always understand why the system is needed and they will always be choice interlocutors. They will still be surprised when you point out the flaws and issues of the mature system you now manage. Because that is not the one they built.

They might have shipped a product indeed: something hopefully iterated on, but their goal was to build the thing that was sold. It isn't that product anymore, it's infrastructure now. One most of its users might not have bought but simply inherited. Something they must use, and will resent if it makes them struggle.

This means that getting the support of the original champions is not always as easy as you would expect. They are design system champions through and through, but it doesn't mean they are immediate sponsors. Their initial understanding of what it takes for the system to succeed has to change, and it's your job to help them. Their expectations need adjusting so they can trust you with their system's future.

Managing mature systems

Can this be avoided? Can you prevent your mature design system from facing those issues by better building your budding one? Probably not, or not entirely.

And it's absolutely fine. Having to adapt to your system's speed being banal is a good problem to have. Having to adapt your communication to newfound success is still a success. And debt management is one of the great constants of the universe, that and Mariah Carey at Christmas. You can plan against most of it, but you can't fully avoid it.

So focus on what you need now, on what will let you get to the mature system. Just know that grail is not really the end of the road. It goes on, if all goes well.