Composability in design systems

When I documented my approach to HTML web components I sang the praises of composability:

Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes.

I feel the same way about design systems. In my experience, the design systems that encourage mixing and matching different combinations are the ones that actually get used.

The design systems that struggle with adoption often have the best of intentions. “Look, there are all these pre-made components for you—you should just use them!” But that can be very disempowering. Where’s the sense of agency in using a pre-made solution?

Robin wrote a fascinating post recently called The Other Side (almost certainly not a reference to the Salter Cane song of the same name). He went from being on a design system team trying to enforce adoption to being on a team on the receiving end:

I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.

But by golly if a design system says “no” to me then I will do my very best to blow it up.

Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!

It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.

There’s a tired cliché of an analogy when it comes to design systems: LEGO. It’s not a good analogy but I think it can help to understand this imbalance.

Remember old-school LEGO? The pieces were unopinionated. You had to use your imagination to combine them into something.

Later we got LEGO kits. You followed instructions to create a pre-ordained final combination.

I’m not just being an old man yelling at a cloud when I say that those later sets were different. Not bad, necessarily. But the fun came from cosplaying as a factory worker rather than inventing from whole cloth.

There are certainly organisations where pre-made kits are going to be useful. But when you start mandating their use, don’t be surprised when you get pushback from designers who miss the combinatorial power of using simple building blocks. As Robin says:

I want the design system to carefully guide me instead of brute-forcing its decisions onto my work.

Brad recently wrote about the art of design system recipes. Recipes are combinations of the building blocks in a design system, but they’re not intended to be The One True Way for everyone else solving a similar problem. It’s totally fine if a recipe is a one-off solution.

The design system’s core components are the ingredients stocked in the pantry. Other product designers then take those ingredients to create product-specific compositions that meet their product needs.

I suspect that a lot of design systems have made the mistake of canonising recipes too soon, mandating their use.

A Darwinian approach works better. If multiple people keep creating the same recipe independently then and only then should it be considered for inclusion in the design system.

A design system team should be reluctant to allow a new component into the inner sanctum. Instead I see design system teams eager to mint as many ready-made components as possible.

But if the true test of a design system is in its adoption, then the safest bet is to stick to the basic building blocks. Support designers by taking care of their baseline needs. But don’t stop them from composing.

Responsive typography and its role in design systems | Clagnut by Richard Rutter

Okay, if you weren’t already excited for Patterns Day, get a load of what Rich is going to be talking about!

You’ve got your ticket, right?

Home | The Component Gallery

Here’s an aggregator of components from multiple design systems.

Adoption. — Ethan Marcotte

Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.

Craft vs Industry: Separating Concerns by Thomas Michael Semmler: CSS Developer, Designer & Developer from Vienna, Austria

Call me Cassandra:

The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:

[…] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality.

This grim assessment is well worth a read. It rings very true.

What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the “output” is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce “free” iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!

Pattern Wise, System Foolish

A library of UX components is one common part of a design system, but the system itself is something bigger. A good system is also a shared set of strategies for solving visual and interactive communication challenges, a playbook rather than a script.

I like this way of putting it:

The problem is that treating a design system as a pantry full of widgets is, in and of itself, a failure of both craft and imagination. Think of it like a language: if a writer’s only engagement with it is grabbing words from the dictionary and heaping them together until “message” is achieved, things are going to suck. Language is more than a bag of words.