|View this newsletter on the web.
Earlier this week, I watched this fantastic talk by Ethan Marcotte about the current state of design systems and I haven’t been able to stop thinking about it. The part that really stuck out to me though was this bit:
Creating modular components isn’t the primary goal or even the primary benefit of creating a design system. And what’s more, a focus on process and people always leads to more sustainable systems.
I love this talk but I find that a lot of the writing about design systems work out there focuses on how to make good docs, how to make things accessible, building marketing sites for your system, or focusing on color contrast. But I think the big weird problem about design systems that no one really talks about is that it can become extremely political.
I tend to forget this because I get so bogged down in the details of a design system, like caring about typography or refactoring CSS, etc. But as much as those details should be sweated, they can sometimes get in the way of bigger improvements that need to be made when it comes to the culture of your organization.
Design systems isn’t just about components, but as Ethan mentions in that talk, it’s about people and process. (I’m repeating this for myself because I keep forgetting that.) What does that really mean? Well, sometimes it’s a better use of your time to try and hire a team instead of fixing this one tiny problem with your docs. Or maybe not a team but just making the case to hire a dedicated front-end/UI engineer, as I’ve been doing this week.
A few weeks ago I realized that I had to snap myself out of trying to fix problems with our components or with accessibility or color and instead try to change the process of our organization and how we build things. Progress can often be made 1% at a time, but sometimes you need to confront the biggest hurdle of working on design systems…
…tackling the politics. Ugh.
Hiring, managing, making the case for a new team. All of that is design systems work just as much as the writing of code or auditing of components. And it can be pretty scary if you’ve never done that before.
My advice is to try and phrase the problem in a way that management will understand. Don’t say “our components are bad and should be better” — focus instead on the business arguments. Why would hiring a UI engineer help the company? How is a design systems team going to improve the bottom line? Making a case for a dedicated person or even a full team is the design systems work at its very hardest; trying to improve the people and the process at the same time. It’s what really differentiates a junior design systems person to someone who’s more senior.
And if I could give myself advice for a second I’d say: be patient, make your case, and then repeat it until it becomes so boring and obvious to everyone else that hiring a team is the right thing to do. It’s tough and can be demoralizing but sometimes is the only way to tackle design systems problems at scale: moaning loudly in a British accent.
Well, at least that works for me.