Down with design systems dogma

As the design systems space has matured, our understanding of what they entail and how to approach the work has naturally converged.

We now have a wealth of collective knowledge and experience that we can use to inform our practice - and that’s a very positive thing.

But convergence can cross over into rigidity. And when contextual experience informs general recommendations, we can find ourselves facing counter-productive dogmatism.

“There’s a right way to do design systems, and we’re doing it wrong”

In 2019, Jina wrote:

“The word “design” and “system” used in combination together literally just means to systemize your design... And so if for you that means a Sketch UI Library, then you do you!”

She asked us to focus less on deliverables, and more on the practice of doing the work.

But from where I’m standing, that message still hasn’t taken hold. Everyday I talk to organisations who tell me things like:

  • “Our designers think their Figma library is the whole design system - we need to focus on the codebase”
  • “Our product teams keep building from scratch instead of using core components”
  • “I can’t get my company to see the point in design tokens”
  • “The developers want to version components individually - but that’s not a system!”

And while the specific problem they’re describing changes - these statements all boil down to the same sentiment: There’s a right way to do this work, and we’re doing it wrong.

This, in my view, is burning us out.

Design systems dogmatism leads to burn out

I have this mental image sometimes of those of us working on design systems as salmon, swimming upstream, in pursuit of what we consider the ideal design system.

Illustration of a salmon swimming upstream after a krill.

The current around us represents our unique context: the specific communities our systems are serving, our organisation’s needs, and the barriers and challenges we face along the way.

And in our pursuit of that one specific vision, we often find ourselves swimming against it.

When this happens, we often find ourselves focusing on the current, and the friction we’re facing.

We find ourselves making no progress, and we start to conclude that “it must be us, or the context, or the people around us”.

The nuance, complexity and variability of the contexts that we’re building our design systems in, is infinite and ever-changing.

But dogmatism in our field is forcing us to try and solve these problems in one way - and we can’t let it.

You are not a salmon

Instead of continuing to swim upstream and stopping only now and then to notice how exhausted we are, I believe that we can give ourselves permission to do something different.

So - just in case you need this reminder - remember that it’s OK to swim with the current sometimes.

It’s OK to choose context over convention: to look at that design systems vision that our industry dogmatises, and to decide to go after something else that works better for you.