I’ve spent the last 15 years as a product designer, and the through-line has been Design Systems. I still remember being the fresh-outta-college design intern trying to convince my first design director to build a "kit of parts" with documentation for devs… back when we were still designing websites in Photoshop and using smart objects as reusable components. Sketch wasn’t even on the market yet, and we couldn’t even conceive of what Figma would allow designers to do.

Design systems have always been a part of my work, and my favorite part, because a well-built system changes how a team operates at a fundamental level. I once took over a three-person design team that the organization had essentially given up on. They chronically missed deadlines, and engineers had started bypassing design entirely to build features on their own. Management knew and didn’t intervene. The team had completely lost credibility to the point where going around it was easier than trying to fix it.

Without replacing anyone on the team, we rebuilt the design system from the ground up, and within a year, design was working a month ahead of engineering and hadn’t missed a single deadline. And this wasn’t a fluke: every team I’ve seen commit to a well-built (and maintained) design system has seen similar transformations.

But when you go looking for guidance on how to do this, especially on a small team with no dedicated resources, most of what you’ll find doesn’t apply. The conversation around design systems is dominated by enterprise voices. Dedicated design system teams, complex multi-product or multi-brand architectures, governance models that assume organizational overhead most teams simply don’t have. That’s not where most of us work. Most of my career has been building and maintaining systems on small teams, the kind where the “design system team” is you, plus whatever time you can borrow from an engineer who has three other priorities. The constraints are different. The failure modes are different. And the payoff when you get it right is disproportionately large, because small teams have the most to gain from a system that actually works.

This gap is about to get a lot wider. AI-assisted development is fundamentally changing how code gets written, and teams without strong design systems are going to feel it first. When engineers can generate features faster than ever, the system is the only thing standing between rapid output and a fragmented product. Small teams that get this right will punch way above their weight. Small teams that don’t will ship faster and faster into an increasingly chaotic and unknowable mess.

That’s what I want to write about, and I’ve got a lot of ground to cover. I think the best place to start is with the ways these systems break down. If we can map the failure modes clearly, we’ll be in a good position to start building something better.