‍

‍

When I started working in design over eight years ago, I didn’t expect to one day lead panel discussions, mentor future design leaders, and shape systems that helped major companies scale. But looking back, each step on that path was important.

Working alongside talented designers and developers — and learning from some of the best mentors in the field — taught me not only how to grow, but also how to guide others. Today, I want to share some hard-earned lessons from my experience with design systems. This isn’t theory — it’s what I learned by doing, by leading, and sometimes by failing.

If you’re starting out or already knee-deep in systems work, these points might save you time — or at least help you feel less alone.

‍

‍

‍

‍

1. A UI Library and a Design System Are Not the Same

At one job, I was asked to improve our UI library. It sounded simple. But as I looked deeper, I saw a bigger issue: we didn’t just need new components — we needed a system to organize and guide their use.

That’s how I built my first design system. It started with Figma’s new auto layout feature, and quickly turned into a full system: documentation, rules, training, everything. That’s when I realized: a UI library is a toolbox. A design system is the manual that tells you how and when to use those tools.

‍

2. Build Your System Like a Product

When I created our system, I wasn’t just building for developers — I was also building for fellow designers. They were my users, too.

Design systems should feel like real products. They should solve clear problems, make work faster, and remove confusion. If your team doesn’t know which button style to use or where to find it, they lose time. A system done right lets designers focus on users and lets developers build faster with fewer questions.

‍

3. Designers and Developers Should Work as One

If your design looks one way in Figma but shows up differently in the final product, users will notice. Inconsistent behavior creates doubt, and that’s bad for any brand.

To avoid this, designers and developers must stay connected. They should build and update the system together, not in silos. This kind of collaboration takes effort, but it’s the only way to keep things smooth and unified.

‍

4. Keep Naming Simple and Scalable

At first, I loved naming color styles with unique names — Chambray, Malachite, Cinnabar. It felt creative. But when we added dark mode, it became a mess. People didn’t know when or where to use which colors.

We had to start over and use practical, context-free names. Simple naming helps everyone work better and prepares the system for future changes like themes or accessibility updates. The coolest name is the one that makes sense.

‍

5. Atomic Design Changed How I Work

I came across Brad Frost’s Atomic Design and it clicked immediately. Building UI with a system of small, reusable parts makes everything faster and easier to update.

This way, one update in a single “atom” can fix dozens of screens. It’s a simple method that helped me avoid chaos and stay consistent. I recommend it to anyone starting a system from scratch.

‍

6. Open Systems Grow Better

A design system should never be locked away from feedback. If teams don’t feel involved, they won’t use it — or worse, they’ll work around it.

The best way to grow your system is to invite others to contribute. Of course, you’ll need rules to keep things consistent, but giving teams ownership helps them understand it better. And when they feel like part of the process, they help make it better.

‍

7. Design Systems Are Never “Done”

Even after years of working with design systems, I still find things to improve. That’s the truth: a system is never finished. It changes as the company grows, as new features are added, and as teams change.

That’s why clear documentation, regular updates, and shared knowledge are so important. When your system is open, modular, and easy to evolve, it lasts. I’ve learned this through experience — leading teams, guiding updates, and revisiting things I once thought were complete.

After years of working with teams across design and development, leading projects, and sharing my knowledge through talks and mentoring, I’ve learned that building a system is only part of the job. The bigger part is keeping it alive — and making sure the people who use it feel supported.

I wrote this to reflect on those lessons — and to help others build systems that last.

‍

‍

Aram Andreasyan
Industry Leader, Design Expert

‍