Using our design system as a strategic tool

Stepping into this phase, the design system itself was no longer the issue. After a year of work, we had a solid foundation in place: tokens, an initial component set for web and mobile, documentation, and clear governance and contribution models. The system was live and readily available…

Yet adoption was slow.

The first guess would be that designers refuse to use the system or don’t consider it up to their standards. But that was not the case. They started using and wanted to use it in their products, but there was no clear mandate from product as it was difficult for them to wrap their heads around the full extent of the system. Below is a concrete depiction as of why that is:

Switching to using the system meant refactoring existing interfaces and absorbing short-term delivery costs, while product planning remained focused on feature output. As a result, the design system was perceived as a “nice to have when we have time” rather than a strategic improvement.

The turning point came when the organization decided to fully redesign KTM’s website and its affiliated brands. For the first time, teams could build directly with the system instead of retrofitting it later. That opportunity also raised the stakes: if the system failed to support delivery, engineers would be blocked and timelines would slip. That was exactly the kind of setup that would be beneficial for the design system.

At this stage, the problem was no longer about design maturity. It was about making the value of the design system tangible for product leadership in terms they cared about: effort, risk, and delivery speed.

As Design System Lead and Design Ops Lead, I had full ownership over the system’s roadmap, standards, governance, and quality. I could define what we built, how we built it, and which contributions were accepted or sent back. What I did not control was product prioritization. The product team had a fixed delivery plan consisting of pages and immovable deadlines. Adoption had to fit within those constraints.

The biggest barrier I had to face was mental, not technical.

Product leadership viewed the design system as a very complex element and thus as a constraint, something “nice to have,” but abstract and costly. Their underlying model was sequential: design → brand adaptation → accessibility → implementation, repeated for each brand that they support (3). That model consumed enormous bandwidth but felt familiar and safe under deadline pressure. They also did not have to explain it to their management.

The difficulty was that this model was optimized for short-term delivery, not for scale. Each step was repeated, effort was hidden inside individual pages (and that is the reason why they speak in terms of pages and not in terms of global system), and the real cost only appeared late, when timelines slipped or quality issues surfaced. The design system challenged this model by forcing those hidden decisions to move upstream.

My goal was then to reposition the design system from an asset library to a decision-making framework, one that replaced sequential rework with shared, upfront decisions about brand, accessibility, and component behavior.

At first glance, this model looks more complex. There are more steps, more checkpoints, and more explicit decisions. That density is intentional. Instead of hiding complexity inside pages and discovering issues late, the design system makes decisions visible earlier in the process. Brand alignment, accessibility, and component reuse are no longer implicit assumptions — they become explicit checkpoints with clear ownership and feedback loops.

While this introduces more structure upfront, it dramatically reduces rework downstream. Consistency is enforced early, gaps are identified before implementation, and teams align on reusable solutions instead of solving the same problems repeatedly. What appears denser on paper is, in practice, significantly lighter to execute at scale.

The first concrete signal that this shift was possible came from design. By working directly with the system, designers were able to design for all three brands significantly faster than before. Cross-brand consistency no longer required additional steps or negotiations, it was embedded by default. Instead of slowing delivery, the system increased output and reduced rework. Designers could focus on creating better experiences than focusing on how they would translate their designs for each brand.

The real shift happened when this change became visible to product. The conversation moved away from whether the design system should be used towards what it would take to cover the full website within it. At that point, the system stopped being perceived as a design concern and became a planning tool. It enabled product to reason about scope, effort, and timelines in a way that the previous sequential model never allowed.

To make the design system legible to product, I stopped advocating through principles and documentation alone and shifted to the language they already used to make decisions. Instead of abstract system concepts, I anchored every discussion in concrete scope, numbers, and delivery impact. System components were mapped directly to real website pages, using their own product as the reference point. This slowed things down initially, but it replaced vague agreement with decisions product could actually act on.

From there, I made the scope of the design system explicit. Rather than presenting it as an open-ended initiative, we identified with the product designers exactly which components were required to ship the new website. Adoption stopped being an ideal state and became a finite, plan-able effort. However, this came with risk: committing to visible scope with limited resources meant real accountability. But without that commitment, the system would have remained abstract and easy to postpone.

To support this shift, I introduced a sizing and estimation model to make the cost of system work explicit and comparable. Tokens, components, and patterns were categorized by size, with modifiers accounting for reuse and complexity. Effort included not only design and code, but also documentation, changelog updates, asset preparation, and verification. This added structure, but dramatically reduced ambiguity.

Finally, estimation stopped being an internal planning artifact and became a shared reference. By aggregating component effort at the page level, product teams could see what was already covered by the system, what remained, and exactly how timelines were affected. Making constraints visible reduced control — but it built trust and repositioned the design system as an integral part of product planning rather than a parallel concern.

Governance was designed to protect quality without slowing teams. The governance and overall process inquires that designers and engineers have mastered their tools to provide the service they have been hired for. We did not account for any knowledge upscaling sessions or support.

Designers contributed via a structured template covering interactions, accessibility, and responsive behavior. Missing information was handled pragmatically: discussed when possible, returned with clear feedback when not.

Once accepted, the design system team owned integration: token alignment, assets, documentation, changelog updates, and verification. Engineers implemented directly in the system codebase and shipped components back into product work.

Exceptions were intentional. Minor component changes required lightweight validation. Patterns were owned end-to-end by the design system team due to their systemic impact.

Authority was distributed. The team operated independently, escalating only for roadmap, timeline, or stakeholder conflicts. Governance enabled scale without turning me into a bottleneck.

Adoption did not happen because the design system was correct or complete. It happened once the system became operationally unavoidable for the success of what the product team was building.

The spreadsheet fundamentally changed the conversation at the decision-making level. For the first time, product leaders could clearly see the effort required to move from a blank page to a shipped one using the design system. Dependencies were explicit. Trade-offs were visible. Most importantly, it showed that components were built once, reusable across pages, and immediately compatible with all brands — instead of being repeatedly redesigned and reimplemented.

This shifted adoption from a philosophical discussion to a delivery decision. Designers no longer had to advocate for the system; they used it as the default and focused on improving it. Engineers became active contributors, integrating components directly into the system codebase as part of product delivery rather than as parallel work.

The clearest signal that adoption was working was the change in questions. Conversations moved from “Why are we doing this?” to “Is this the right abstraction?” and “How can this component be improved for future use?” At that point, the design system had stopped being a proposal and had become infrastructure.

In retrospect, the most impactful change I would make is involving product earlier with concrete planning artifacts. We initially underestimated how overwhelming the design system could feel from a product perspective, not because of resistance, but because its size and implications were abstract. The spreadsheet ultimately solved that problem but it should have existed sooner.

One trade-off I would make again without hesitation is the time invested in accompanying designers through the contribution process. As delivery pressure increased and product alignment lagged, this created friction. Designers were often caught between design system expectations and product timelines. That friction, however, was productive. It surfaced misalignment early and directly led to the creation of the spreadsheet and the end-to-end process mapping that enabled adoption at scale. Without that investment, the system would have remained technically correct but organizationally on the low.

This experience fundamentally shaped how I lead today. It reinforced that accompaniment, not mandate, is essential when changing how people work and collaborate at scale. Progress only became possible once I actively listened across disciplines and understood how constraints were experienced differently by designers, engineers, and product managers.

At the same time, it clarified that empathy alone is not enough. Effective leadership requires holding a clear position and accepting constructive friction when necessary. Some of the most meaningful improvements emerged precisely because tension was allowed to exist instead of being smoothed over.

From a scaling perspective, this work reshaped how I think about building teams and systems. Scale is not achieved through additional rules or headcount, but through shared mental models, explicit decision frameworks, and distributed ownership. My role as a leader is not to remove constraints, but to make them visible, intentional, and usable so teams can make better decisions independently and move faster together without losing coherence.