A fragmented design landscape across three brands was slowing teams down and eroding product quality. In one year, I built a scalable multi-brand design system that unified design practices, improved accessibility, and gradually shifted teams toward building products through the system rather than around it.
Context
When I joined LX Media as UX Designer, the organization had already attempted to build a design system twice. Both initiatives failed to gain traction due to a lack of centralized ownership, limited design systems expertise, and little alignment between departments and subsidiaries.
As a result, designers worked with scattered and often outdated assets. Color values differed slightly from one file to another, multiple icon sets coexisted, and components existed in several variations depending on the project. There were no shared design principles, no clear documentation, and no reliable handoff process to engineering.
With roughly ten designers distributed across different projects, this fragmentation created visible inconsistencies in the interfaces we shipped. Designers regularly recreated patterns that already existed elsewhere. Engineers had difficulty translating designs into reusable code. Product teams repeatedly debated visual and functional inconsistencies across products.
Previous attempts had shown that tooling alone would not solve the issue. What the organization lacked was not just a component library, but a structured approach to ownership, governance, and collaboration.
Challenge
The objective was not simply to create a component library. The real challenge was to establish a design system capable of supporting three distinct brands — KTM, Husqvarna, and GasGas — while working across multiple platforms including web, iOS, and Android.
Each brand came with its own visual identity, color palette, typography, and iconography. At the same time, several brand assets did not fully meet accessibility standards, meaning the system needed to balance brand expression with usability and WCAG compliance.
Another challenge came from the organizational structure. Designers, engineers, and product teams were distributed across multiple projects with different priorities and timelines. Introducing a design system meant influencing teams to adopt shared foundations while they were still shipping features.
The goal therefore became twofold: create a technical system that could scale across brands and platforms, and build the organizational structure required for teams to adopt and contribute to it.
Strategy
From the beginning, it was clear that the system could not be built in isolation. Adoption would only happen if teams felt involved in its development and understood its value for their work.
Instead of immediately focusing on components or tooling, I started by assessing the state of design across the organization. This allowed me to identify structural gaps and define a first proposal outlining how the system would function.
The proposal addressed three key areas:
1. The structure of the design system itself This included defining where tokens would live, how theming would support multiple brands, and how the system would integrate with engineering workflows. 2. Collaboration with product teams Designers and engineers needed clear ways to request components, report issues, and contribute improvements. 3. Documentation The system required a central source of truth where teams could understand how components worked, how to adopt them, and how to contribute.
This proposal created the initial alignment required to begin building the system while keeping stakeholders informed and involved.
Execution
Once the structure was defined, we began with the system’s foundational layer: design tokens.
The first iteration consisted of a small JSON file containing core tokens such as colors, typography, and spacing values. These tokens were connected through Style Dictionary, allowing them to be synchronized between Figma and our front-end codebase.
This token-based approach ensured that the system could scale across platforms and brands without duplicating design work.
Over time, the system expanded significantly. The original MVP evolved into a more robust architecture supporting:
At the same time, our documentation platform evolved. Early versions relied on a SaaS documentation tool, but its limitations eventually pushed us to build our own internal documentation service. This allowed the team to structure the content and contribution flows exactly as needed.
The system gradually transformed from a small technical experiment into a scalable infrastructure supporting multiple products.
Supporting three brands introduced a complex constraint: each brand had its own visual language, but all products needed to meet accessibility standards.
To understand the scope of the problem, I conducted a full accessibility audit across brand assets. The results showed that several colors and UI patterns did not meet WCAG contrast requirements.
Addressing this required collaboration with the teams responsible for brand identity. We standardized several design elements across brands, including icon styles and shape systems. Some surface colors were adjusted to ensure sufficient contrast while still preserving brand identity.
These decisions were not arbitrary. Each recommendation was presented with before-and-after comparisons and supported by accessibility guidelines and usability standards. The branding teams accepted the proposals, which allowed the system to move forward with a shared visual foundation.
Another unexpected challenge emerged around language. Product teams—particularly those working with CMS platforms—often used different terminology than the design system. For example, elements described as “components” in the system were referred to as “sections” in the CMS environment.
To address this, we aligned terminology where possible and clarified definitions in documentation to reduce misunderstandings.
Adoption began naturally with designers, by integrating the system into Figma libraries, designers could start using shared tokens and components directly in their workflows. However, adoption across product teams proved more complex.
Engineers often encountered designs built with system components that had not yet been implemented in their codebases. This created friction between design and development. Rather than avoiding this friction, we used it to highlight the need for adoption.
Teams gradually realized that delivering features would become easier once the design system was integrated into their workflows. To support this transition, I introduced a contribution model that defined how designers and engineers could participate in the system’s evolution. The model provided a clear process for requesting components, reporting issues, and contributing improvements. This contribution flow was documented on our platform and regularly referenced during discussions with product teams.
Adoption progressed differently across teams.
Mobile teams were among the first to adopt the system’s foundations, reserving dedicated time in their roadmap to integrate tokens and base styles. Web teams began preparing adoption alongside a new website project, identifying which components were required for launch.
Adoption remains a gradual process, influenced by project timelines and available resources. The design system team tracks this progress internally as part of broader design team OKRs.
Impact
The most visible impact of the design system has been cultural. Designers increasingly start new work directly from the system rather than creating patterns from scratch. They challenge the system when it does not meet their needs and contribute improvements back to it. This shift signals that the system is no longer seen as a separate initiative, but as a shared foundation for product development.
Engineering adoption is progressing more slowly, largely due to resource constraints. However, collaboration between designers and engineers around the system is steadily improving.
The system now supports multiple products across brands and platforms while providing a shared language for teams building digital experiences.
Next steps
While the foundations are now in place, the system continues to evolve. Upcoming work includes introducing UX patterns to ensure consistent experiences across products. Examples include standardized patterns for loading states, messaging, and offline behavior.
In parallel, the team is investing more effort in research around the documentation platform. Understanding how teams navigate documentation will help us improve discoverability and usability.
Finally, we are developing ways to measure the impact of the design system more systematically. Metrics such as design velocity, adoption rate, time to market, and code quality will help us better understand how the system supports product development.
Reflection
Building a design system at this scale is not primarily a design challenge. It is an organizational one. The work involves aligning stakeholders, adapting communication for different teams, and maintaining momentum across multiple projects with competing priorities. It also requires patience. Adoption rarely happens all at once. Instead, it emerges gradually as teams experience the benefits of shared foundations.
The system is still evolving, but its role within the organization has changed. What began as an initiative to reduce inconsistencies has become a core part of how teams design and build digital products.