When Design System Adoption Wasn't a Component Problem

The organization was trying to improve design system adoption by improving the portal. But people were not struggling only because components were hard to find. They were struggling because they needed different kinds of trust, guidance, flexibility, and support.

01 · The symptomAdoption looked inconsistent across roles

Designers, developers, product owners, content strategists, and accessibility experts were all expected to build reusably. Some wanted more flexibility. Some needed clearer rules. Some wanted to contribute back to the system. Others wanted trusted examples they could apply quickly.

At first, this looked like a portal problem. Improve search. Reorganize content. Add missing documentation. But those fixes would only solve part of the issue.

Original frame

Improve the portal so users can find components, guidance, and documentation more easily.

Research reframe

Understand the mindsets behind adoption, then design the ecosystem around how people build, trust, contribute, and comply.

Strategic shift

The work moved from fixing screens to improving the adoption system: onboarding, support, contribution, governance, and measurement.

02 · Deep listeningWe asked how people think, not just what they do

I used one broad question to guide the research: What goes through your mind when you think about building reusably?

Across 38 interviews, the goal was not to collect feature requests. The goal was to understand the beliefs, fears, habits, and decision patterns behind reusable design.

This helped the team move past roles and look at the deeper reasons people adopt or avoid a design system.

Deep listening research approach for reusable design interviews.

Research setup. The interviews were short, flexible, role-agnostic, and focused on the job to be done rather than the product itself.

Behavioral themes defining design system persona mindsets.

Pattern synthesis. Six behavioral dimensions helped explain how people approached flexibility, innovation, inspiration, compliance, feedback, and contribution.

03 · Finding patternsThe mindsets emerged from behavior, not titles

The interviews showed that job title did not predict adoption behavior. A developer, designer, or product owner could all need the same kind of guidance depending on the work and the risk.

The behavioral dimensions clustered into three recurring mindsets: The Pathfinder, The Creative, and The Rule Follower.

A person could shift between these mindsets. The model was not meant to label people. It was meant to help the team design the right support for the right adoption behavior.

04 · The modelThree mindsets explained the adoption behavior

The mindsets helped the team understand why people in different roles behaved similarly, and why people in the same role often needed different support. Adoption was shaped by autonomy, competence, and relatedness, not just by job function.

A behavioral model, not a role-based persona set

Mindsets × motivation

Autonomy, competence, and relatedness plot showing Rule Follower, Pathfinder, and Creative mindsets.

Why this mattered: The model helped the team design for motivation and confidence, not just for roles like designer, developer, or product owner.

05 · The strategyEach mindset created a different adoption risk

Once the mindsets were clear, the team could stop debating generic improvements. The better question became: Which adoption behavior are we trying to change?

Each mindset valued the design system differently. Each one also put a different business metric at risk if the system did not support them well.

Differentiation at a glance

Research → opportunity → KPI risk

Mindset differentiation table comparing values, guiding principles, motivations, opportunities, and KPI risk.

The important part was not the table itself. It connected mindset, value, motivation, opportunity, and business risk. That moved the conversation from portal content to adoption behavior.

06 · The service shiftThe portal became part of a larger adoption model

The portal still needed to improve. But the research made it clear that adoption depended on more than navigation and search. Users also needed onboarding, documentation, community channels, office hours, contribution paths, governance, and support.

The design challenge shifted from make the portal easier to use to make the design system easier to adopt.

Pathfinder

Make contribution visible

Clarify paths to patterns, examples, and contribution beyond components.

Creative

Preserve autonomy

Provide inspiration, rationale, and flexible guidance so the system does not feel restrictive.

Rule Follower

Increase trust and clarity

Prioritize guidance, best practices, compliance, and trusted examples.

07 · Research synthesisFrom interviews to the service ecosystem

The mindset framework came from a larger map of how teams build applications reusably, from onboarding through delivery.

The modified map shows the full research synthesis and a zoomed area where specific onboarding and support needs became visible.

This helped the team see that adoption issues were spread across the service journey, not isolated inside the portal.

Modified mental model and opportunity map with zoomed detail.

Research synthesis. The map connected interviews, journey stages, friction points, and more than 350 opportunity ideas across the reusable application experience.

08 · The ecosystemDesigning for the Rule Follower first

The service map was built around The Rule Follower, the mindset most dependent on guidance, structure, and clarity. This was an intentional choice.

Many teams optimize for advanced users first. We made a different decision. If onboarding, contribution, and support worked for the most guidance-dependent user, they would naturally reduce friction for the other mindsets too.

The service map became a shared reference for aligning portal, community, support, and engineering investments around the complete adoption journey.

Future-state onboarding and contribution ecosystem

Service map · generalized for portfolio

Future-state onboarding and contribution service map for the Rule Follower design system mindset.

Future-state service map for the Rule Follower mindset. The map connects platform touchpoints, community interactions, support channels, measurement opportunities, and business outcomes across the adoption journey.

09 · What changedFrom portal improvements to adoption investment

The work helped the team move from a feature wishlist to a clearer adoption strategy. Instead of treating every request as equal, improvements could be sequenced by the adoption behavior they supported.

Research impact

Roles became mindsets. The team gained a better model for understanding adoption behavior across designers, developers, product owners, and partners.

Product impact

The portal was redesigned around behavioral needs. The team moved away from organizing only by content category.

Service impact

Onboarding and contribution became part of the experience. The work extended into support, community, and governance.

Roadmap impact

Investment moved toward adoption drivers. More than 350 opportunity ideas were synthesized, and the prioritized ones were translated into roadmap direction across awareness, adoption, engagement, satisfaction, and retention.

10 · ReflectionThe contribution was changing the adoption frame

The biggest lesson was not about design systems. It was about adoption.

Organizations often invest in making tools better. The harder challenge is helping people change how they work.

Research became valuable because it reframed adoption as a human system rather than a technology problem. Once the problem changed, the roadmap changed with it.