Where the team thought the problem lived.
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.
Adoption 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.
38 interviews, one question.
We 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.
Behavior predicted adoption. Job title did not.
The 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.
Autonomy, competence, relatedness.
Three 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
Why this mattered: the model helped the team design for motivation and confidence, not just for roles like designer, developer, or product owner.
Each mindset put a different metric at risk.
Each 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 to opportunity to KPI risk
The important part was not the table itself. It connected mindset, value, motivation, opportunity, and business risk, which moved the conversation from portal content to adoption behavior.
From easier to use, to easier to adopt.
The 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.
Make contribution visible
Clarify paths to patterns, examples, and contribution beyond components.
Preserve autonomy
Provide inspiration, rationale, and flexible guidance so the system does not feel restrictive.
Increase trust and clarity
Prioritize guidance, best practices, compliance, and trusted examples.
Friction was spread across the journey.
From 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.
An intentional choice about who to design for first.
Designing 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
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.
A wishlist became a sequence.
From 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.
Artifacts are included as portfolio evidence with sensitive details generalized or intentionally unreadable at full-page scale. The case study focuses on the research logic, service design approach, and strategic decisions rather than confidential internal content.
The contribution was the reframe.
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.