Tagged with design systems

Smart take here from Jeremy about composable design systems:

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.

Jeremy argues that design systems should have many small pieces that can be easily reconfigured—and this happens to tie in nicely from another post of his about HTML web components:

...what if my web component needs to do two things?

I make two web components.

The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.

Yes! This is precisely why I started ranting a while back about how, 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 from: everything has one job, does it really well (ideally), which makes the possible options almost infinite.

Design systems should hope for the same.

The other day I mentioned Saneef Ansari’s excellent postcss-design-token-utils that converts a bunch of JSON into custom CSS properties and utility classes. At the end I aggressively rambled about how much I’d love to see this as a dedicated website and, well, Saneef built the darn thing!

It’s called Design Token to CSS and it’s very much worth checking out. I’ve fallen out of the loop a little bit when it comes to syncing design tokens like this between Figma and your front-end codebase but I imagine this is extremely helpful for keeping designers and engineers on the same page there.

Also! This tool is part of Saneef’s collection of “nano-sized tools for web designers” called nanools which I had never seen before but holy heck is color × color worth looking at as well. It lets you build full blown color systems—but I especially love how Saneef goes about explaining luminance, chroma, and hue.

Eric Bailey has some great thoughts about why it’s tough to show success on a design systems team:

In a business context, design system work means numbers go down. Less bug reports, faster design iteration, shorter development cycles, fewer visual inconsistencies, smaller staffing requirements that enable folks to work on more interesting challenges, etc. All good things.

Unfortunately, contemporary business practices only reward numbers going up. There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.

This is an interesting discussion because it’s hard to quantify what’s good work when it comes to design systems. For example, when I was on a team like that I would struggle to make the case for refactoring tons of janky and confusing CSS.

Ultimately I felt like I was good at the systems part—I could tell when there were too many similar components or when we should refactor something—but I was really, really bad at the storytelling part of design systems. And that kind of work is really more story than systems: explaining to folks up the chain why this seemingly insignificant series of tasks is an investment in the future. Or why this one tiny detail is worthy of our care today so we don’t have to worry about it later.

A while back I rambled out loud about how some design systems are way too strict:

Being on the other side of design systems now as a product designer is super interesting. I kinda hate the rules and regulations and nitpicking! And if I can’t lean into the system then I will fight against it with every fiber of my being.

So, okay, what parts of a design system should be strict and which parts should allow for more flexibility then? For example, design tokens should probably be super strict. You should rarely add a new font size or color variable or space things out with 7px when your systems sets an 8px scale. Adding a new font to a design system should also be a very slow and deliberate process that shouldn’t be rushed. So that’s a no-go, too.

However, components should be pretty locked down. You should be allowed to add components back to the system but a design systems team should be able to step in and demand that you use the standardized Button component over NewFancyButton. Otherwise all hell breaks loose and you have 5 different versions of everything.

However, however: adding variants of a component should be pretty lenient. If I need to add a green button to the design system then I don’t think that’s where a ton of oversight should be required to stop that because a variant doesn’t do as much damage as a whole new component might.

My rambling point here with all this is that there’s a spectrum of strictness when it comes to design systems and I think a lot of the work I did in the past ignored that. I saw our component library as being this pure and perfect thing that shouldn’t be messed with. But such intense strictness actually ended up hurting our team in the long run: folks didn’t want to contribute or help make things more consistent across the product. I still struggle, generally, with wanting to be right all the time. I want to correct all the wrong-ness in the world! And when it comes to design systems there’s so much sillyness and incorrectness and misbehavior that I want to sweep it all away with a wave of my hand.

But being useful is almost always better than being right. Both in life generally and also when it comes to our work in building sustainable and kind design systems.