Things I Learned as a Design System Designer

When I first stepped into the world of design systems, I thought I was just trading screens for components. I didn’t expect it to reshape how I think, collaborate, or even name a button. Over time, I realized design systems aren’t just about consistency — they’re about clarity, scale, and the quiet glue that holds product teams together. Here are a few things I’ve learned (sometimes the hard way) on this journey.

Design Systems are about people, not just components

It's easy to think a design system is just a library of buttons, inputs, and styles. But behind every component is a network of people — product teams, engineers, fellow designers — all trying to build consistent experiences at scale. My job is less about making a perfect button, and more about making sure that button works everywhere, for everyone.

Tokens are tiny but mighty

The first time I heard about "spacing tokens," I almost tuned out. It felt abstract and overly technical. But once I understood how tokens drive consistency, flexibility, and even accessibility — I realized they’re not just implementation tools, they’re design decisions codified.

Documentation is a design artifact

I used to think design ended at the Figma file. Now, I know that writing clear documentation is part of the craft. When a developer understands how and when to use a component without needing to ping me, that’s design working at scale.

Naming things is a UX problem too

Naming a component or a token isn’t just about clarity for me — it’s about clarity for everyone who touches it later. Ambiguous names create confusion, versioning issues, and friction. Precise, consistent naming = smoother teamwork.

You need to zoom out… a lot

In product design, I focused on one screen, one journey. In systems work, I think across platforms, teams, and use cases. You have to constantly zoom out, look for patterns, and ask: “Will this still work when things scale?”

Cross-functional alignment is half the job

Design systems live at the intersection of design and engineering. Most of my time isn’t spent just designing — it’s aligning. Syncing with devs on implementation, resolving naming conflicts, prioritizing updates with product teams — this collaboration is where the real impact happens.

Perfection is the enemy of scale

When you’re working on a product, it’s tempting to tweak that 1px misalignment or obsess over corner radius. In systems work, perfectionism can slow things down. Clarity, consistency, and usability matter more than visual micromanagement.

You still design for users — they’ve just shifted

Your “users” in system design are often internal — designers, engineers, and writers. If they can’t use the system easily, it breaks. So I started applying the same empathy I had for end-users to my teammates using the system.

Final Thoughts

Becoming a design system designer wasn’t just a role shift, it was a mindset shift. It taught me to think in patterns, write with intention, and solve for scale. Many of these lessons were shaped not only through my day-to-day work at John Deere, but also through conversations and insights from the design community. Events like Config 2025 and Into the Design System deeply influenced how I think about system design, collaboration, and the evolving role of designers in large ecosystems.

If you’re curious about this path or navigating it already, I’d love to hear your story too.