Design systems for designers

If you’ve ever worked on software design, from mobile consumer apps to b2b saas apps, to web design, to just about anything that will touch code, you’ve likely encountered or been told about design systems.

There’s a million articles on this topic, courses, classes, and an overwhelming amount of information on how to do this the right way.

Most of that just isn’t helpful in the real world.

For the last decade I’ve worked on design systems of all types. I’ve created some from scratch for small startups, maintained or supported or added onto design systems for larger companies and teams, and worked with developers to create a (mostly imaginary) 1-1 relationship from a design file to code.

Figma is now the tool of choice for nearly all teams I’ve worked with in the last decade, although Sketch is a slight holdout in some areas. Typically a design system is a series of components in one of these design tools, corresponding to components in code. So when you drop a button onto the canvas from your library in Figma, you can drop the same component in your code and they’ll look identical at the end.

So if you’re a newish designer, or a designer wondering just what you’re missing, you’ve likely been asked in interviews, or discussed with team members, where a design system can fit in.

This is tricky. If you’re a programmer it’s akin to unit tests. They’re important, you know you should do them, you want to do them, you probably have done or are doing them at some levels, but you always have this creeping feeling that there’s more you can do.

The challenge with design systems is they can become prescriptive instead of supportive, they can force teams into a constrained, predefined way of thinking, without allowing for the constant changes and shifts that can and will happen in creating good software.

Too often teams rely on the crutch of the holy grail of a design system, here to solve every problem the team will face. And when problems happen, and boy do they happen, we bemoan the lack of the design system which would fix all this.

That’s not to say design systems aren’t valuable. When they’re working, when they’re up to date, when you can quickly go from an idea to code because you’re pulling pieces together and shipping, they feel like this magical unicorn that turned a messy project into a delight.

Design systems have tremendous value, and for that reason we chase them, looking for that productivity boost, that thing that’s already been thought out for us, here to save the project.

It may sound like I’m down on design systems. I’m not. In fact I’ve used them to build apps in days, relied on them to keep teams on the same page across complex software and through hundreds of components, and built them myself to quickly ship things.

The thing I push back on, is this idea that they should be perfect, immutable, and that if I could design the system just right all my problems would be solved.

Through years of on-the-ground learning I’ve seen design systems have their use, speed up time to ship, and become a supporting tool for product manager, designers, and engineers to work together and create software.

But I haven’t worked on a single design system that accounted for everything we needed. Too often a new idea, feature request, or affordance, would come into play and the design system couldn’t account for it.

Ah, you say. Just update the design system.

The challenge isn’t in a lack of desire or will or laziness, but rather a practical reality I’ve seen where design systems just fall out of step with code and what really exists in the wild with customers. Even the most fastidious designer, whose job it is to maintain the components, cannot keep the relationship between code and design held together.

By necessity you’re duplicating effort. You’re designing in one place and programming in another, and gaps will appear. If you’re making great software, and shipping ideas quickly, you’ll fall out of sync. You can say that you’ll spend time on design debt, and pull the two back together. But the second law of thermodynamics is fighting against you, and it’s a battle you will lose.

So my approach to design systems has relaxed. I appreciate them, maintain them when I can, use them as inspiration, but don’t allow them to be a rigid blocker for the things we want to build. A little design debt can be managed, if you’re focused on the reason for your product’s existence, if you’re working toward the goals and metrics that matter.

Here then is my approach in 2025 to design systems. When I sit down to create a screen in an app, I first check the design system to see what components are available. Then I look at what’s alive in the wild and screenshot the components already used. I then dive into my design process. I scour other verticals for ideas, re-write the goal I’ve been tasked (or tasked myself) to work on, and then sketch out the user experience that accounts for all of the pieces laid out in front of me.

Then, when it comes time to go to hi-fidelity design I’ll use the design system, create new components where needed, then work with a developer to ship it and test, learn, and repeat.

When other designers or managers ask me about design systems, my answer is that I use them where available, build them when needed, but treat them like a supportive guide, and not an enforced requirement for the design to follow.