CASE STUDY / DESIGN SYSTEMS / UX ARCHITECTURE / GOVERNANCE
Scaling design beyond components
How I expanded a design system into a governed UX architecture, helping teams spend less
time recreating common solutions and more time delivering and measuring customer value.
ORGANIZATION
National Bank Independent Network · Compass wealth management platform
MY ROLE
Program Lead · Principal Designer
SCOPE
Design systems · UX architecture · governance · product quality
TEAMS SUPPORTED
Compass feature teams, the product design & research team, and firm and partner
developers integrating with the platform
TIMELINE
2021 — Present
01 / THE OPPORTUNITY
Component consistency did not guarantee experience consistency.
Our design system had created a shared visual language. Designers and engineers could
reuse foundations and components instead of rebuilding buttons, inputs, colours, and
typography for every product. But teams still had to determine how components should
work together to support common customer tasks. The same problems were being solved
repeatedly across products.
SOLVED AGAIN IN EVERY PRODUCT
Searching
Filtering
Onboarding
Completing forms
Managing permissions
Handling errors
Reviewing complex data
The component library was working. The system surrounding it needed to evolve.
A SECOND LAYER OF DESIGN-SYSTEM DEBT
01
Similar workflows behaved differently across products.
02
Teams assembled the same components into inconsistent experiences.
03
Designers spent significant time resolving previously solved problems.
04
Accessibility and content requirements were applied unevenly.
05
Product teams measured individual features but rarely the effectiveness of shared
patterns.
06
Decisions about the system were fragmented across teams.
07
The design-system team became a service desk rather than a strategic capability.
02 / REFRAMING THE DESIGN SYSTEM
Standardize the decisions that did not need to be made repeatedly.
Expanding the design system beyond visual components meant building a UX architecture: a
shared model for how navigation, workflows, content, states, permissions, accessibility,
and measurement work together across products. The goal was not to standardize every
experience. It was to give product teams more time to focus on the problems genuinely
unique to their customers and business domains.
THE ORIGINAL SYSTEM ANSWERED
What reusable interface elements should teams use?
TO SCALE DESIGN, WE NEEDED TO ANSWER
How should our products behave when customers perform recurring tasks?
03 / BUILDING THE UX ARCHITECTURE
Five connected layers, from tokens to product experiences.
I organized the expanded system into five layers. Each layer built on the one beneath
it, and each answered a different question: what the visual and technical language is,
which elements to reuse, how elements combine to complete a task, how tasks compose into
coherent products, and where product teams adapt the shared baseline to their own
domains.
05
PRODUCT-SPECIFIC EXPERIENCES
Product teams used the shared architecture as a starting point, then adapted it to
the needs of their customers and business domains. The system reduced repeated
decisions while preserving room for product-specific discovery, experimentation, and
innovation.
WHERE TEAMS ADAPT, DISCOVER, AND EXPERIMENT
Shared baseline in. Product-specific discovery, experimentation, and innovation out.
04
EXPERIENCE ARCHITECTURE
Connected individual patterns into coherent product structures. This layer allowed
multiple products to feel related without forcing them into identical layouts.
Global and local navigation
Information hierarchy
Page and workflow composition
Authentication and permissions
Cross-product transitions
Responsive behaviour
Localization
Accessibility
Customer-support touchpoints
Analytics and measurement
03
INTERACTION PATTERNS
Explained how multiple components should work together to help customers complete a
recognizable task. A component tells a team how a control works. A pattern explains
how the complete interaction should work.
Search, filter, and result exploration
Complex data-table interaction
Multi-step form completion
Review and approval
Empty, loading, success, and error states
Permission and access management
Notifications and activity history
Onboarding and guided setup
Editing and saving
Destructive actions and recovery
02
COMPONENTS
Translated the foundations into reusable interface elements. Each component
documented its states, behaviour, content guidance, responsive rules, accessibility
requirements, and implementation.
Buttons
Inputs
Selectors
Tables
Cards
Navigation controls
Dialogs
Alerts
Status indicators
01
FOUNDATIONS
Established the basic language of the product ecosystem, creating consistency at the
visual and technical level.
Colour
Typography
Spacing
Grid and layout
Motion
Iconography
Content principles
Accessibility requirements
Design and engineering tokens
04 / FINDING THE HIGHEST-VALUE PATTERNS
Tied to product needs, not a documentation exercise.
We did not begin by attempting to document every interaction. I worked with designers,
engineers, product managers, researchers, accessibility partners, and customer-facing
teams to identify where reuse could create the greatest value, then prioritized patterns
based on frequency, customer importance, implementation cost, risk, and potential reuse.
WHERE WE LOOKED
01
Patterns repeated across multiple products
02
Areas generating usability or support problems
03
Workflows with high customer or business risk
04
Features creating repeated design and engineering effort
05
Accessibility issues appearing across teams
06
Inconsistent experiences affecting customer trust
07
Places where product teams lacked evidence for decisions
08
Upcoming roadmap work that would benefit from shared solutions
PRIORITIZED BY
FREQUENCY
CUSTOMER IMPORTANCE
IMPLEMENTATION COST
RISK
POTENTIAL REUSE
05 / DESIGNING PATTERNS AS PRODUCTS
Each pattern was a small product, not a static template.
Where evidence was incomplete, patterns entered the system as hypotheses to be piloted
rather than permanent standards. This allowed the architecture to grow through use and
learning.
A PATTERN DEFINITION INCLUDED
STATUS: PILOTING
The customer problem it addressed
Recommended interaction flow
Accessibility behaviour
Implementation guidance
Examples from real products
When the pattern should and should not be used
Component composition
Responsive and localization considerations
Measurement recommendations
The task or outcome it supported
Content and terminology guidance
Required states and edge cases
Known limitations
06 / MOVING REPEATED WORK INTO THE SYSTEM
Reuse was not about speed. It created capacity for better product decisions.
Instead of starting from a blank canvas, teams could begin with an evidence-informed
baseline. Designers focused discovery on what was specific to the product. Engineers
received clearer behavioural and accessibility requirements. Product managers gained a
more predictable view of design and implementation scope.
BEFORE: EVERY TEAM ANSWERED AGAIN
How should this workflow be structured?
Where should validation happen?
What happens when there is no data?
How should customers recover from an error?
How do permissions affect the experience?
What should happen on smaller screens?
Which analytics events should be recorded?
How will we know whether this interaction works?
AFTER: TIME SAVED WAS REDIRECTED TOWARD
Customer research
Testing risky assumptions
Prototyping new product directions
Evaluating released experiences
Improving underserved journeys
Measuring whether the product created the intended value
07 / EMBEDDING MEASUREMENT INTO THE SYSTEM
Adoption tells you a component is used. It doesn't tell you the experience works.
Traditional design systems measure adoption. Those measures are useful, but they do not
show whether the resulting experience works for customers. We expanded measurement
across three levels, and measurement requirements became part of the pattern definition.
Shared analytics events and success criteria travelled with the pattern into
implementation.
01
SYSTEM ADOPTION
Can teams find, understand, and implement the available patterns?
POTENTIAL MEASURES
Pattern adoption across products
Reuse versus local duplication
Contribution and review cycle time
Version and deprecation status
Documentation usage
Designer and developer satisfaction
02
DELIVERY EFFECTIVENESS
Do shared patterns improve the way teams deliver products?
POTENTIAL MEASURES
Time from design start to development readiness
Design and engineering rework
Accessibility defects
Inconsistent local implementations
Design-system support requests
Time spent resolving repeated interaction decisions
03
CUSTOMER EFFECTIVENESS
Do patterns deliver the customer outcomes they were intended to support?
POTENTIAL MEASURES
Task completion and completion time
Error and abandonment rates
Support requests
Feature adoption
Accessibility outcomes
Customer confidence or satisfaction
Successful recovery from errors
Progression through onboarding
08 / ESTABLISHING GOVERNANCE ACROSS TEAMS
Federated ownership: neither a central bottleneck nor fragmentation.
A central team could not understand every domain or create every pattern. At the same
time, fully distributed ownership would allow the system to fragment again. Governance
existed not to create control, but to maintain quality and shared ownership.
CORE SYSTEM TEAM
MAINTAINED
Foundations and components
UX architecture principles
Documentation standards
Accessibility and quality requirements
Pattern lifecycle and releases
Cross-product consistency
System-level adoption and effectiveness measures
PRODUCT & DOMAIN TEAMS
CONTRIBUTED
Emerging patterns from real product work
Domain requirements
Customer evidence
Implementation feedback
New states and edge cases
Results from experimentation and measurement
CROSS-FUNCTIONAL REVIEW
Design, engineering, product, accessibility, content, and research representatives
reviewed patterns with broad impact, focused on four questions.
01
Does this solve a recurring customer problem?
02
Is it supported by evidence from more than one local use case?
03
Can teams implement it accessibly and reliably?
04
How will we measure whether it is effective?
09 / CREATING A PATTERN LIFECYCLE
Untested solutions could not become standards. Useful ideas were not delayed.
Every proposed pattern moved through a visible lifecycle. This prevented untested
solutions from becoming standards while allowing useful ideas to enter the system
without excessive delay.
PROPOSED
PILOTING
APPROVED
MAINTAINED
DEPRECATED
01 PROPOSED
A team identified a recurring problem or reusable solution and supplied evidence from
product work.
02 PILOTING
Tested in one or more products, gathering usability, implementation, accessibility,
and measurement feedback.
03 APPROVED
Sufficient evidence, documentation, and implementation support for broader adoption.
04 MAINTAINED
Monitored across products and improved as customer behaviour, technology, and business
needs changed.
05 DEPRECATED
Replaced through a clear migration process when no longer the best available solution.
10 / ALIGNING TEAM TOPOLOGY TO THE ARCHITECTURE
The central system created leverage. Embedded teams preserved understanding.
The expanded design system also clarified how design capabilities should be organized.
The topology balanced coherence with local autonomy: the central team's role was not to
complete product-team work, but to make product teams more capable of completing that
work consistently.
EMBEDDED
EMBEDDED PRODUCT DESIGNERS
Remained close to customers, product strategy, and domain-specific problems. Applied
and tested shared patterns while identifying new needs.
ENABLING
DESIGN-SYSTEM & UX-ARCHITECTURE TEAM
A central enabling team maintaining foundations, components, patterns, documentation,
tooling, and cross-product quality.
FEDERATED
FEDERATED DOMAIN CONTRIBUTORS
Designers and engineers from product teams contributing specialist knowledge and
real-world evidence without leaving their domains.
SHARED
SHARED SPECIALIST CAPABILITIES
Research, content design, accessibility, analytics, and UX engineering participating
where patterns crossed products or carried significant customer risk.
11 / WHAT CHANGED
From a component library to an organizational capability.
Teams gained shared answers for recurring experience problems while retaining the
flexibility to solve genuinely new ones.
01
More consistent workflows across products
04
Faster movement from concept to validated implementation
07
Shared measures of experience effectiveness
02
Less repeated design and engineering effort
05
More intentional use of specialist capabilities
08
More design capacity for customer research and innovation
03
Clearer accessibility and content expectations
06
Stronger governance without centralizing every decision
09
Continuous improvement based on evidence from multiple products
The UX architecture adopted the bank's enterprise design system as its foundation and
extended it with a platform navigation model and a Module Federation extensibility
model, so new modules could ship into Compass without re-solving shared journeys.
Effectiveness was measured through the usability testing process and product analytics
instrumentation established for the platform, with feedback from firms in the alpha and
beta programs feeding the pattern lifecycle. The developer experience built for firms
and partners let third parties integrate against the same patterns, and the platform
vision behind the architecture helped secure $31M in investment over four years.
12 / MY LEADERSHIP CONTRIBUTION
I reframed the design system from reusable components into a UX architecture.
This required aligning product, design, engineering, accessibility, research, and
customer-facing teams around a shared model of reuse. The result was not only a more
mature design system. It was a clearer operating model for scaling design across teams.
01
Establishing the architectural layers
02
Identifying and prioritizing high-value patterns
03
Defining how patterns should be documented and measured
04
Connecting the system to product delivery and customer outcomes
05
Creating a federated contribution and governance model
06
Clarifying ownership across central and embedded teams
07
Establishing a lifecycle for testing, approving, maintaining, and retiring patterns
08
Helping leaders connect system investment to product quality and organizational
capacity
Five lessons carried forward from the work, each one shaping how I think about design
systems as organizational capability rather than component inventory.
A product can use the correct buttons, inputs, and colours while still providing an
inconsistent experience. Patterns connect the components to customer goals.
02
Governance should accelerate good decisions
Governance becomes harmful when it exists mainly to approve work. Its value is
providing clear ownership, reusable evidence, and faster paths to quality.
03
Reuse should create capacity, not just efficiency
The most valuable result of a design system is not producing the same interface more
quickly. It is giving teams more time to understand customers, test ideas, and improve
outcomes.
04
Measurement belongs inside the architecture
If teams wait until after release to decide how success will be measured, useful
signals are often missing. Patterns should include measurement intent from the
beginning.
05
Systems must learn from products
The design system should influence product work, but product evidence must also
influence the system. A healthy architecture creates a continuous exchange between
central standards and local learning.
14 / CLOSING
Not identical products. More capable teams.
Scaling design required moving beyond a library of reusable parts. By adding interaction
patterns, experience architecture, measurement, and federated governance, we created a
system that supported the complete customer experience, not only its visual components.
Teams could spend less time repeating established decisions and more time understanding
customers, exploring new opportunities, and evaluating whether the product delivered
meaningful value.
That was the real purpose of the system: not to make every product identical, but to
make every team more capable of creating effective experiences.
NEXT / 05 PRODUCT DISCOVERY
How an innovation workshop created a new direction for project discovery