Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”
HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.
Design systems should hope for the same.
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.
This great post by Mandy ticks all my boxes! It’s a look at the combinatorial possibilities of some of the lesser-known HTML elements: abbr, cite, code, dfn, figure, figcaption, kbd, samp, and var.
This looks like fun: it’s like a clever slot machine for pairing typefaces.
I thought the “machine learning” angle sounded like marketing bullshit, but it’s genuinely fascinating.