Lumora is a platform that helps businesses grow online by connecting them with top-tier publishers and making SEO and content strategy easier, faster, and smarter.
When Lumora approached us, they were at a critical growth stage — rapidly expanding their platform, adding new features, and onboarding clients at scale. But internally, things weren’t as streamlined. Components were being rebuilt from scratch, handoffs were messy, and the design-to-dev process lacked structure.
They didn’t just need a fresh coat of paint — they needed structure.
As the Design Systems Designer, I partnered with two other designs and a front-end developer to create a scalable design system. Our goal was to bring consistency, speed, and clarity to Lumora’s growing product, and lay the foundation for future growth.
While exploring the design files and reviewing the live product, I noticed something off. Could the developers be working from outdated assets? To validate my suspicion, I ran a quick audit of the site. I discovered that not only were the assets widely different, there were so many variants of buttons, badges, and other components.
We wish we were born knowing how to create design systems. When we started, we honestly had no idea how to organize all the components or where to even begin.
Thankfully, design systems from companies like Shopify, Google, and Apple were available for us to explore. They were helpful and inspiring — but also massive and sometimes overwhelming. They gave us a vision, but not a step-by-step path.
What really helped us move forward was learning about Atomic Design principles. Breaking things down into atoms, molecules, and organisms made the process feel a lot less intimidating.
It wasn’t enough to just make things look good in Figma — the system had to work in code, too. So, we brought in a front-end developer early on and started building the system together.
We aligned on the basics: naming conventions, design tokens, component structure, and usage patterns. We also embedded helpful dev context directly into Figma — things like token references, class names, and usage notes — so that handoff wasn’t just visual, but actionable.
Having a development background myself made a big difference. It helped me think beyond the canvas — to understand how developers interpret design, where friction usually happens, and how we could remove it.
From the start, we knew this system wasn’t just for us — it was for future designers at Lumora, too. As the product scaled, so did the need for a system that could grow with it.
We kept things simple and flexible by using atomic design principles to create small, reusable components. Nested components and properties helped minimize variant overload, while still supporting real use cases.
Rather than covering every edge case, we focused on adaptable patterns and clear documentation — leaving space for the system to evolve over time.
The design system is still a work in progress and continues to evolve. After we started using the new components, we checked in with the dev team to see how things were going. They shared helpful feedback on what was working well — and what still needed improvement.