Our team has been discussing changing some existing design system components this week. The increasing complexity involved got me thinking.
I think our design system is hitting its “tweens.” It’s still immature in a lot of ways — this has been a concerted effort less than 12 months — but we’re now experiencing both growth spurts and growing pains. Finding out some decisions we made aren’t quite fit for purpose or didn’t account for unforeseen scenarios is natural but that doesn’t make dealing with it any easier.
This adds a new factor to prioritisation. We were previously balancing three main areas of work:
- Foundational work to enable us (like the solidifying our colour system, etc.)
- Designing and building new components
- Refactoring production code to use components
Now there’s a fourth competing concern, or a 3B: Addressing shortcomings of our components.
By that I mean not only updating them to be more appropriate for new design work — while considering the constraints of existing implementations — but also updating them in production.
We’ll need to decide when it’s the right time or important enough to make something better, and when to make do with what we have. And that’s too complex for one person to decide alone; those decisions and tradeoffs need to account for design priorities, engineering priorities, and capacity across both sides.
Design systems are not easy.