Client
Moz Pro
My Role
Design Lead
Dev Lead
Casey Coates
Building a scalable Design System for a Leading SEO Tool in North America - Powered by AI plug-ins and proper UI Tokenization.
I initiated a project to turn our messy, unstructured Pattern Library into a Design System. To tackle this challenge, I focused on two things:
Tokenizing fundamental UI elements using Figma variables - laying the groundwork for consistency and scalability.
Collaborating closely with the frontend engineers from day 1 to maintain a sync between design and the live product.
The result? Through design reviews, implementations, QAs, and engineer feedbacks, we built a solid foundation for a design system that not only cleaned up UI debt but also set our product up for scalable growth.
UI Elements Tokenized
Components Created
Component Usage Rate
For two years, as our product expanded, our pattern library kept growing without a structured cleanup. Every new addition piled on top of the last, creating a fragmented, inconsistent mess. UI elements were all over the place, and our components no longer matched what was live in the product. Time for a reset!
When I audited our entire Figma file to start, I uncovered two major issues:
1️⃣ No tokenization – We had decent colours, spacing, and typography, but they were stored as Local Styles, rather than Variables, making every little updates tedious and repetitive.
2️⃣ Aging components – Many hadn’t been properly maintained for years, leading to big discrepancies between design and code base (Storybook JS).
We decided it was an opportunity to future-proof our product with a design system and bring clarity to chaos.
Issue 1 - Local styles in Figma are static and hard to manage, while variables offer scalability and flexibility.
Issue 2 - For some of the components, there's a huge gap between the design and the codebase.
I knew building a design system was a big ask, so I focused on the fundamentals — Tokenizing the core UI elements (colours, spacing, typography, etc). Because without a structured system, every small change to the pattern library would create redundant work and inconsistencies.
Thankfully, Figma Variables had just launched a year ago, offering a game-changing way to create design aliases (Tokens) that reference variables. To get the team on board, I ran a live demo, showing how tokenization could streamline updates, improve efficiency, and bring long-term consistency to our design workflow.
We decided to start small, focusing on colour tokens first.
At first, the team was unfamiliar with variables, but once they saw how it simplified their work, they were in.
I audited all the colours used in our product and compared them with what’s in the code!
From there, I cleaned up the redundant colours that had built up over the years and developed a tokenized colour system with a clear naming convention, working closely with the frontend team.
It’s crucial for design to create naming conventions that seamlessly integrate with frontend workflows rather than disrupt them.
Cleaning up the redundant colours.
Coming up with a Naming Convention TOGETHER with the frontend team.
From day one, we started a shared knowledge base with the frontend engineer because designing in isolation just doesn’t work for building design systems.
I can’t emphasize enough how important it is to work closely with frontend engineers. We do design reviews, collaborate on implementation, QA together, and continuously refine the system based on feedback. A design system isn’t just about design, it’s a team effort to create something scalable, efficient, and truly usable.
A knowledge base for all resources from Design & Frontend Engineer.
By meticulously cleaned up the first component, I ensured all properties were set correctly with variants, booleans, and instance swaps. Then it's time to build out its documentation, including:
✅ Purpose & Use Case
✅ Best Practices (Do’s & Don’ts)
✅ AI-generated Component Anatomy & Property Table
✅ Accessibility Rules (Colour Contrast & Compliance)
And that was just for one component. Before moving forward, I synced with the team to make sure everything was aligned then repeated the process!
Ensuring all component properties were set correctly with variants, booleans, and colour tokens.
Drafting a Purpose & Use Case section for the Design System documentation.
Adding a Do’s and Don’ts section to help guide future additions to our design system.
Using an AI plugin, I generated a component anatomy, making it crystal clear for frontend engineers to reference.
Adding accessibility rules to ensure our design system is professional and inclusive.
This is still an ongoing project that I spend time on a daily basis. But here's some learnings.
1️⃣ Don’t Accumulate UI Debt. Maintain Components Regularly
Waiting too long to clean up components only makes the problem worse. A design system isn’t a one-and-done project—it requires ongoing maintenance to stay efficient and usable. To prevent things from piling up, a few suggestions:
✅ Scheduling regular design system check-ins.
✅ Hosting weekly meetings or office hours with frontend engineers.
✅ Ensuring reusable components are properly implemented and updated.
A well-maintained design system saves time, reduces inconsistencies, and streamlines collaboration between design and development.
2️⃣ Leverage Figma’s Full Power. Embrace New Tools & Technology
Figma’s Variables, AI plugins, and other advanced features have completely changed the way we build and scale design systems. Instead of sticking to outdated workflows, exploring new tools and approaches can make processes faster, more efficient, and more scalable.