I’ve worked in the design industry for over eight years, and during that time, I’ve had the chance to work with amazing teams, learn from respected mentors, and lead projects that shaped how large companies build and use design systems. I’ve also mentored many professionals — some of whom are now known in the design world — and have led panel discussions where we talked about design challenges, solutions, and what it means to build something that works.
One of the earliest memories that comes to mind is a long meeting where my team and I spent hours discussing something as small as the corner radius on a button. It wasn’t just about the pixel — it was about building something bigger: a system that would later be used by engineers, designers, and product teams across the company. And like many teams, we made the mistake of focusing too much on the visuals in the beginning.
If your team has ever felt like it’s going in circles trying to get a design system off the ground, you’re not alone. I’ve seen it happen again and again — teams stall because they’re chasing perfect designs instead of setting up a working process. A design system isn’t just about making things look good. It’s about creating a shared language between design and engineering, and that doesn’t happen without strong communication and smart planning.
One thing I’ve learned is that a design system without engineering support is just a visual guide. If you want your system to live, grow, and be used, bring in your developers from the start. I’ve seen what happens when designers try to build something alone and hope for buy-in later. It rarely works. Instead, the most successful design systems I’ve helped build were rooted in strong collaboration with engineering teams.
Engineers need to be more than participants — they should be advocates. When they build the components themselves and see the value of the system, they’re much more likely to support and spread its use across teams.
When we launched the first version of our design system, I wasn’t thrilled with it. It didn’t look polished, and some components didn’t quite work together. But we made the right choice by putting it out there. Once it was live, we could improve it. We could test new ideas, learn from real usage, and grow the system naturally.
I always remind teams: a design system is a living thing. The first version isn’t final. You’ll keep improving it as you go. The important part is starting. Let designers explore, let engineers build, and let teams use it — even if it’s not perfect.
The turning point in our journey was when we began setting clear rules and processes. We brought in a design operations manager to focus on the system full-time. We also hired a skilled principal designer to work across teams and help others understand how to use the system effectively.
We asked important questions: How do teams request new components? Who approves changes? What does success look like in terms of adoption? These decisions gave us clarity. They also helped us scale the system in a way that worked for the whole company.
It’s easy to get caught up in visual details, but in my experience, real success comes from strong foundations. That means involving the right people, focusing on process early, and staying flexible as the system grows.
Over the years, I’ve seen design systems fail because they looked great on paper but never made it into daily use. I’ve also seen rough first versions evolve into tools that shaped how entire teams work together. What made the difference wasn’t the design — how we built, shared, and supported the system.
Looking back, I’m proud of the roles I’ve taken in shaping these systems and leading discussions that inspired others. I’ve learned that being a good designer means more than creating beautiful screens — it means thinking beyond pixels and helping teams work better together.