Design System Adoption

Industry

Furniture Retailer

Team

2 people

Duration

12 months


My role

  • Lead strategic designer

  • Reframed the brief, defined project goals, scope, and strategic direction

  • Led research, synthesis, and translation of insights into actionable recommendations

  • Translated research insights into actionable frameworks and recommendations aligned with business goals

  • Designed and facilitated workshops to align stakeholders, test assumptions, and shape business direction

  • Coached a junior design researcher and managed senior stakeholders

THE BRIEF

Increasing adoption & staying relevant in a maturing organisation

The client had invested heavily in building a design system and educating designers about it, yet adoption had stalled.

The brief — increase adoption and deepen how teams engaged with the design system, ensuring it remained relevant as the organisation matured rather than fading into a “one-off initiative.”

REFRAMING

Listing the assumptions

The brief arrived framed as a design problem. As with all briefs, it carried assumptions about where the issue lay. In this case, the underlying belief was that improving the design system offerings would significantly increase adoption.

A review of adoption data confirmed that adoption had plateaued well short of saturation, making it a problem worth investigating.

The next question was why.

Through stakeholder interviews, we surfaced the assumptions shaping the organisation's view of the problem. We then made the most consequential ones explicit and prioritised the ones that would most strongly shape the direction of the work. These became the starting point for fieldwork and early conversations.

I work this way because assumptions shape how a problem is understood. Testing them early helps establish whether the organisation is pointing at the right problem before it spends on the wrong one.

Key assumptions

More is more: increasing the design system’s component offering will lead to higher adoption through increased usage.

01

Adoption is owned at the ground level. But despite an investment in education and upskilling, it has stalled due to resistance to change and established working habits.

02

03

Adoption is a binary state: a team has either adopted the design system or not.

“Deeper engagement” with the design system will only be achieved when product teams change their WoW and contribute back to the design system.

04

PROCESS & OUTCOMES

Findings, Reframes & Outcomes

This was not an offering issue—it was a communication gap. The financial value of the design system was not being articulated at a strategic level, limiting its prioritisation.

Finding 01

Adoption was treated as a downstream design issue, despite strong advocacy from designers. Middle managers deprioritised migration to the design system amid competing demands. At the executive level, business leaders were unaware of its cost savings, so the mandate was not reinforced from the top down—resulting in a largely bottom-up effort.

Reframing

Identified executive stakeholders in adoption
Uncovered business leaders as critical indirect stakeholders for prioritisation & adoption.

Created role-based communication guidance
Identified direct and indirect stakeholders of the design system. Created guidance on how, when, and at what level (tactical or strategic) to communicate with each stakeholder group to secure buy-in and drive adoption.

Opened up the financial narrative
Framed cost savings as the key executive message, enabling narratives such as “The Story of a Button,” which quantified the value of the design system through tangible cost metrics.

Established a communication diagnostic system
Created a framework to measure communication effectiveness across roles and adoption stages, introducing quantitative tracking and a baseline for year-on-year evaluation.

Outcome

How was this created?

Conducted qualitative research with direct and indirect users of the design system to understand their needs and test hypotheses around how the system could better support their use cases. This surfaced communication as a key gap. Synthesised findings into role-based journey maps and ran workshops to map existing communication, identify breakdowns, and explore how messaging should shift across roles and adoption stages. Supported this with ideation sessions to define and test narrative approaches.

Built a communication diagnostic framework (survey-based) to measure communication effectiveness across roles and adoption stages, establishing a baseline for ongoing tracking and maturity assessment.


Teams had varying levels of design maturity, yet adoption expectations were uniform. Many had initiated adoption but stalled midway, feeling unsupported by the design system team and unable to successfully complete implementation.

Finding 02

Design system adoption is not a binary state—it is a progressive journey that requires teams to be met where they are and actively supported through it.

Reframing

Maturity-based adoption framework
Defined design team maturity levels grounded in organisational reality, and the conditions needed to progress between the levels, including technical enablement, capability building, and adoption support.

Opened up adoption support channels
Shifted adoption from self-service to a shared responsibility between product teams and the design system team. The design system took on a more active support role and established structured support channels. Direct user engagement surfaced internal blind spots that were resolved to reduce adoption barriers.

Successfully onboarded a low-maturity franchisee
Enabled a low-maturity franchisee to move from local solutions to full adoption of the design system, supported by the maturity framework and structured adoption support and then scale region-wide.

Outcome

How was this created?

Adoption Framework: Conducted field research with Swedish teams at varying maturity levels, using interviews and workshops to identify adoption barriers. Synthesised the findings into a maturity framework, then validated and refined it through real-world application with a low-maturity franchisee in Spain.

Structured Support: Facilitated sessions to define how adoption support could be prototyped and made more accessible. This led to a deliberate decision to test Slack as the low-cost initial support channel and learn how users engaged with an early-stage structured support model.


A shared north star requires clear, common definitions of contribution and collaboration, so teams align on what each means and how each should be supported.

Finding 03

Everyone agreed the design system needed contribution and collaboration to stay relevant, but neither was clearly defined; the terms were used interchangeably and interpreted differently across the organisation.

Reframing

Created a shared understanding of contribution vs collaboration
Defined and differentiated contribution and collaboration, aligning internal stakeholders on what each mode meant in practice.

Clarified requirements and support for both engagement modes
Recognised contribution as clearly scoped and able to emerge organically, and collaboration as more ambiguous, requiring structured resourcing and intentional facilitation. This helped design-system leadership make a clearer case to senior leaders for the resources and support needed to enable collaboration.

Outcome

How was this created?

Early research surfaced the question: “What do you mean by contribution and collaboration?” These terms were used interchangeably across teams, creating misaligned expectations and no shared understanding of engagement across contexts.

Through qualitative research and workshops with product teams and design system stakeholders, we explored how engagement worked in practice and used previous projects as reference points to clarify what contribution and collaboration looked like in real examples. This led to a structured engagement model that clarified how each mode should work and aligned expectations across teams and leadership.


Contribution to the design system was not systematically prioritised by product teams. With delivery work taking precedence and no incentives embedded in team priorities, contributions remained sporadic.

Finding 04

Contribution cannot be treated as a passive input stream when it is not embedded in team priorities or incentives. To evolve as a product, the design system must create structured and intentional ways to learn from its users.

Reframing

Defined systemic constraints on contribution
Named the key organisational barriers limiting contribution to the design system, including incentives, influence dynamics, and capacity constraints shaping what gets contributed and by whom.

Built capability for proactive insight-gathering
Shifted responsibility for insight gathering to the design system and coached the team on how to actively collect user input.

Implemented structured feedback mechanisms
Introduced a set of approaches for gathering input into the design system, of which three have been implemented:

  • Design System Awards Program (recognition of contributors)

  • Cross-over Programs (deep dives into complex team needs)

  • Embedded Engagements (in-context discovery within live projects)

Outcome


THE IMPACT

What change did my work lead to?

Reframed design system adoption from an offerings problem to a gap in financial value communication at the executive level, unlocking sustained adoption growth through leadership support.

We also developed repeatable mechanisms for bringing in user input so the design system can evolve, grow, and stay relevant.

01

A low-maturity franchisee implemented the design system worldwide (across 6 offices) once the underlying blocker was cleared.

02

Restored momentum for design system adoption through leadership-level financial backing, accelerating adoption through executive support.

03

Leadership-specific training was rolled out to help senior stakeholders understand the financial cost and savings of the design system.

Three new ways of bringing user research into the design system are live: Contributor Awards, Cross-Over Programs, and Embedded Engagements.

04

Established a dedicated support channel for design system adoption support.

05