Using your own design system
A while back I took a job working on one of those big, legit design systems — not as a side project, but as my full time gig.
My partner in design was a gifted designer/developer. We had a team of React coders. We served a bunch of products and a crowd of adopters.
Skills sharpener, eye opener
From the beginning, I was learning a ton. Hyper-focused on components, colors, accessibility, spacing, and other abstractions, free to obsess over the smallest details. I guess this is how some people become UI encyclopedias.
I also served dozens of product designers across different teams. Developers too. And did you know designers are opinionated? Design choices, documentation, tooling, all needed to be really solid to withstand scrutiny.
It helped to back things up with research, secondary and primary. This made our recommendations feel less like personal opinions.
And for every designer who leaned on our system as a critical tool, someone else used it grudgingly. Plenty saw us as an existential threat and maybe wanted to discredit us. It became part of my job to share system-related success stories, through the eyes of the product makers.
To be fair, we got plenty of things wrong. By working closely with our adopters, I could see where our assumptions failed and how to adjust. Luckily we updated our design system in regular versions.
Living in the house you built
Things change, and after many months I joined one of the product design teams I had been supporting.
With bias, I sunk my teeth into the design system as a valuable tool, making superfast prototypes.
But some of my teammates viewed things differently.
- When someone wanted to change text colors in a component, I said the system wouldn’t do it, and that this was kind of the point. I might have heard mumbling as I walked away.
- A developer used the design system without the help of a designer. The end result wasn’t great, and the design system took the blame.
On the ground, there were some clear misconceptions about what the system was and how it worked.
Which brings us to the present day, and a consideration of what educational points might be covered for designers willing to be part of the conversation.
- The design system does not replace the designer, unless the designer is redesigning patterns that probably shouldn’t be reinvented. Time gained can be used to test and iterate.
- It’s not all-or-nothing. If the system doesn’t cover a precise product need, a designer is free to adjust and innovate. Is it really better to start everything from scratch?
- The designs they create (maybe for a portfolio) aren’t worth as much if they aren’t developed in code and used by people. Working within a system increases the chances that a design will be built as intended.
- It can be taxing for some designers to change how they work. Show them how to use your system, and provide support whenever and however you can. If something is overly tedious, fix it.
In spite of the negativity, good things are happening in our product.
- Stars are aligning, as designers and developers find themselves speaking a common language.
- Our live product is becoming more consistent with others in the suite — and not just in theory.
- A designer who hadn’t leveraged the system just inquired about giving back to it, helping to enrich a component’s behaviors. If someone feels like a contributor to a system, I think they are more likely to use it.
- My old design system team is still at it, with a new version coming soon. I can’t wait to see what they add.
After experiencing a true design system from more than one angle, I feel affirmed in the belief that systems work — and should be embraced by companies that have the scale to justify them.
I’m more aware that not all designers share this view, but wonder how much of the resistance is based on misunderstanding.
