Takes best served hot

I recently saw this post by Karolina Szczur speaking on “design systems”, the name of the practice we take on. I’ve seen the debate before, and largely avoided thinking about it because my branding skills have room for improvement.¹

Though in my own post earlier this week, I call out a concern I have. Design systems are growing in popularity. This sounds like a good thing. More people are talking about it, and I’m seeing more roles trying to cover it. However, I’m afraid the word “design systems” is loaded across tech at large.

A few months ago I raised my frustration with people claiming they made a design system from vibes. In short and in my opinion, it’s not a design system unless it comes from the Systems region of Design represents agreement in an organization. It’s why I don’t claim having a design system for my personal websites. Are there components and variables to help style the elements? Yes. Did I have to get agreement on what those things are amongst other stakeholders? No. That’s the difference because that’s the real work.

Roles shifting

Other roles also don’t mean what they used to mean. People who used to have the word “front end” in their title used to deal in HTML & CSS. The shift that has happened is “front end” now means JavaScript in the client and on the server. The HTML & CSS part has less emphasis. It’s been shown in the lack of assessment in hiring for technical roles. It’s been tucked away into frameworks that are meant to solve the problem that is CSS where the problem was it didn’t feel like “real programming”. Designers are now expected to push code as part of the role, even seeing the HTML & CSS that was lost to “front end” now appear in those roles.

Returning to design systems, I’ve spoken with recruiters trying to hire for design systems roles and found that the confusion is hindering the hiring. In some cases, the hiring manager is actually looking for a brand or visual designer. They want to take the aesthetic of the product to the next level. While I think many design systems people can do that, they don’t do it in the way these folks are expecting. We create the infrastructure that supports that behavior. We enable the playground. All those design tokens we keep talking about? That’s the way a visual designer can modify the final presentation in one place and affect the entire experience uniformly in the most beautiful way they can dream up.

The role is now going through changes like the examples above. Where our role has been responsible for producing high-quality components and instructing teams on how to use them, the age of AI has caused both of those responsibilities to be different. Components are cheap to make and use, and anything that wasn’t done correctly today can be updated tomorrow. What hasn’t changed is our responsibility to demonstrate what quality looks like at the organizational level.

Notes on quality

Design QA is often relegated to the designer who produced the mockup. That’s a siloed review. It only looks at one small part of the larger application and if the result matches this individual’s expectation. It would be beneficial for some role to look at QA up higher, and that has always been a design systems practitioner’s responsibility. This is where we’ve been thought of as police, governing design across a landscape.

What quality means is dependent on the organization and its culture, as much as I’d like it to be universal. This definition of quality is part of the agreement that we’ve been responsible for since the beginning and how we handle it is the perception that teams have in our role. Are proper color contrast for interactive elements “quality” or are using the right brand colors? Hopefully, it’s both. This is why design systems tend to be different. Each organization has a different definition of done, and further, perfect.

Importantly, this does not mean that I, or other design system practitioners, don’t care or contribute to that definition of quality. We are a part of the organization too, and should have influence on what quality means as well. However, there are often many others who influence and drive the direction of design. Not including people in these decisions causes rogue design to be shipped in secret. The opposite is also true. Those who don’t know about the shared agreement will also go rogue. It’s why the role is more about people and less about patterns. Making components is easy, getting people to agree on them is hard.

Where I sit

For me, after years of doing work in tech, I align most with Design Ops. The role of design operations is often to “unblock” design. Traditionally, this is the team that might help schedule user interviews, or help give access to design software. In contrast, design systems has often been seen as “blocking” design. Practitioners try to stop bad practices from happening so the product is consistent and of high-quality. I’m guilty of this behavior too. Thinking that all the time I’ve spent researching a pattern would somehow sway the larger organization because it was done for them. After all, I’m not using these components myself. I made them for you.

I think differently now. Teams won’t stop making components themselves. They are focused on their own definition of success, hyper-specific to their area of responsibility. This doesn’t give them the opportunity to go into the details often like I might. I also cannot improve every component that gets made, especially when they can change overnight. What I can do is convey what we’ve agreed to be quality across the organization and make it easy for the things we make to improve easily.

That’s my role, whatever it’s called.