TL;DR

CM.com’s design system had no owner, no roadmap, and 80% of dev teams were building their own components instead of using it. I took the lead, reframed Aurora around real user patterns instead of isolated components, and built the business case that turned it into a funded program used by 30+ teams.

Results: +87% adoption · ~1,700 dev hours/year saved · Dark Mode shipped in 2 weeks · 95% of components WCAG/EAA compliant

Context

Aurora is the Design Language System of CM.com, a company with 30+ development teams and products ranging from CPaaS and SaaS tools to Ticketing, POS, and AI services.

When I joined, Aurora was a basic Sketch library maintained by volunteers who met twice a year for two sprints. It had no ownership and no long term strategy, and design and code were drifting apart fast:

• 70% of Sketch components were constantly detached.

• 80% of development teams preferred to code their own components.

• A median client used 6 apps across 2 business units and faced weeks of learning curve for similar actions, which led them to contact support.

Leadership saw Aurora as low value, because nobody could show how many teams used it or what it improved. The team’s frustration was growing, and people were leaving. That’s when I decided to take the lead of the project and started with three key decisions.

Decision 1: Focus on patterns, not components

Task: Understand how Aurora was really being used, and define a strategy to unify all products.

Together with my Lead, we mapped 50+ apps and 65 components, running workshops with 15+ teams of designers, developers, users, and product owners. What seemed like a quick inventory became a large scale discovery, because many apps had legacy versions only reachable through internal URLs. To get real data, we implemented usage tracking across the company and manually audited Sketch files for detachment and duplication.

The findings were clear:

• 45 of 65 core components had development duplicates, and 25 had design duplicates.

• 60% of duplicates had conflicting naming and styling.

• Tables, forms, and analytics pages behaved differently from app to app.

But the most important insight came from watching how users actually moved across apps. Testing a single button in isolation was like reinventing the wheel, because it didn’t reflect how users completed real tasks. So we shifted the focus from components to patterns that support user goals, such as adding, editing, deleting, or searching for information.

In short, we moved from “Let’s make a combobox because everyone has one” to “Let’s make a combobox that supports the real user patterns in our platform.”

Since this still felt abstract for many people, I translated the findings into visual overviews showing how patterns repeated across products. I then ran a pattern sprint using one shared structure for every pattern: References → Platform mapping → Needed components → User tasks & iterations → Notes. This gave all designers across business units one shared knowledge base, so they knew what existed, what other teams were building, and what to prioritize.

Decision 2: Turn a side project into a funded program

Task: Secure resources and executive support.

Good intentions weren’t enough. Aurora needed to show its value in business terms. I presented the audit to Product and Business leadership, focusing on the cost of doing nothing: the duplicated components alone represented ~1,700 extra development hours per year, and that number would grow as the company scaled.

Impact:

• Four dedicated Aurora sprints per year approved by management, making it an officially supported project.

• Design and development seats per sprint committed by individual business units.

• Aurora was added to the company’s WBSO innovation program, linking design system work to CM.com’s strategic R&D.

  
  

Decision 3: Run a system without a dedicated team

Task: Keep Aurora motivating for the people building it.

Even with official support, there was no fixed dev team. We “recruit” developers for every sprint, and they dedicate part of their time for two weeks while competing with their main projects. Engagement wasn’t a nice-to-have. Without it, Aurora would stop.

So I treated our contributors as users too:

• Positioned Aurora as a space for innovation, not maintenance, where people could experiment and learn new skills.

• Personalized assignments based on each developer’s skills, interests, and energy levels.

• Used our CDP to plan sprints with data, understanding contributor profiles and preferences, down to collaboration style and snacks.

• Introduced small rewards, nudges, and achievements to keep motivation high.

• Made the work visible through kick-offs, demos, and presentations at Dev Days and Quarterly meetings, recognizing every contribution.

Impact: Every Aurora sprint has been fully staffed, with growing interest from new contributors. Developers now become Aurora advocates in their own teams, and the project is seen as professional, organized, and inspiring.

Scaling Aurora

With strategy, funding, and people in place, the next step was to make the system itself scalable.

Migrating to Figma

I ran a market review, got buy in from design and development, and led the migration as Figma Admin. I defined tokens, variants, and naming conventions. Color was the biggest challenge, since naming ranged from raw HEX codes to random names like “Blue-12,” so I ran focus sessions with designers and developers to align on categories and propagation rules. Some designers resisted the switch at first, and personal guidance plus hands-on workshops helped them gain confidence.

Impact: Completed in 5 months, with 100% of design teams in Figma, 75% fewer detached components, and Dark Mode shipped company wide in 2 weeks instead of months.

Building the Aurora website

The first challenge was changing the mindset that the DLS site was “only for developers.” Based on focus groups and usability tests with developers, designers, and product owners, we built a hub with components, patterns, templates, usage guidelines, and developer tools like an interactive playground. For a while I managed the UX content (usage, accessibility, content guidelines) alone in a developer-oriented company.

Impact: Used daily by 30+ teams, onboarding reduced from weeks to days, integration time cut by an estimated 30%, and 40+ improvement suggestions received in the first quarter.

Leading accessibility

With the European Accessibility Act approaching, I joined the IAAP, worked with Legal and Compliance to prioritize products, and created an AI prompt template to audit components for accessibility gaps, then validated the results with testing. ARIA implementation was complex and many developers were new to accessibility, so it became a shared learning journey.

Impact: 95% of components meet WCAG and EAA standards. We delivered VPATs for the main apps, and Aurora became the driver of company-wide accessibility compliance.

Results

Aurora is now a recognized and essential standard at CM.com, part of the company’s Innovation Focus Projects, with contributions from designers, developers, product owners, and compliance teams.

✓ +87% Adoption rate
✓ 60% Faster design-to-dev handoff
✓ 75% Fewer detached components
✓ 30% More concept contributions

Aurora is also now the foundation for AI at CM.com, from our AI pattern library to generating front-end prototypes with Aurora components through an MCP server. Want to know more? Check the case study: [AVA Agent: Defining the Role of AI]

What I learned

Data unlocks support. Aurora didn’t fail because people didn’t care. It failed because nobody could prove its value. The moment we showed the cost of duplication in hours, the conversation with leadership changed.

A design system is a people project. The components were the easy part. Keeping volunteers motivated, convincing designers to change tools, and getting developers to trust the system took most of the work.

What I’d do differently: when we started the project AI was still not a stronger tool as we have now in 2026. I learned that using bases as Shadcn could help the process to be faster and easy to manage using a strong fundation.