Design Systems | Enterprise SaaS | Platform Unification
One Advarra Design System
How I built a shared design and engineering foundation across five greenfield and two legacy applications after rapid acquisition-driven growth.
- 7 apps System Adoption
- 5 Greenfield Apps
- 2 Legacy Apps
- 1 Shared Token Foundation
01 | Overview
Context and Scope
Following a series of acquisitions, Advarra's product portfolio had become fragmented, with each application evolving independently across teams, stacks, and decision models.
I led development of a cross-product design system to support a unified One Advarra experience while active product delivery continued across multiple initiatives.
The outcome was a scalable system grounded in tokens, reusable components, and governance that improved consistency while accelerating implementation across seven applications.
02 | Problem Space
Fragmented Portfolio, Shared Expectations
-
Post-Acquisition Fragmentation
Each application had separate patterns, component decisions, and UX conventions, creating a disconnected product experience.
-
Branding Did Not Equal Product Consistency
Aligning colors and typography alone was not enough to create a cohesive enterprise workflow experience.
-
Multiple Tech Stacks
Legacy systems varied by framework and architecture, limiting direct component reuse and requiring system-level abstraction.
-
No Dedicated Design System Window
The system had to be built alongside existing product work, with limited capacity and constant delivery pressure.
-
Weak App-Level Guidance
Existing brand guidelines were web-focused and did not provide enough direction for enterprise interface patterns.
-
Infrastructure Transition in Motion
Standards such as package distribution and pnpm adoption were evolving while the system was being implemented.
03 | Users
Three Groups, One Foundation
-
Primary User
Product Designers
- Need a single source of truth for reusable patterns
- Need faster iteration without reinventing core UI
- Need alignment between Figma decisions and shipped code
- Need clear accessibility defaults in design artifacts
-
Primary User
Frontend Engineers
- Need token-driven standards that work across stacks
- Need reusable components that accelerate delivery
- Need package and release workflows that scale
- Need predictable implementation guidance and docs
-
Business Outcome
Product Organization
- Need cohesive One Advarra customer experience
- Need reduced design and implementation drift
- Need less duplication in UI decision-making
- Need a system that can evolve with roadmap pressure
04 | Approach
How I Built It
- 01
Define a Token-First Strategy
I standardized foundational decisions at the token layer to create cross-stack consistency without requiring a single framework-specific component implementation.
- 02
Accelerate with Curated Component Foundations
Instead of building every primitive from scratch, I selected and customized a third-party component framework to support immediate product delivery while the system matured.
- 03
Synchronize Design and Code
I aligned Figma and implementation through token synchronization and shared component patterns so teams could move from concept to code with fewer translation gaps.
- 04
Stand Up Cross-Functional Governance
I organized a design-engineering working group with recurring sessions, reviews, and showcases, treating the system as a product with active roadmap ownership.
- 05
Institutionalize Documentation and Distribution
I implemented tooling and process through Knapsack documentation plus CI/CD-based package distribution via GitHub and Artifactory, with support for npm, yarn, and pnpm.
05 | Key Decisions
System Decisions That Scaled
- 01
Prioritize Tokens Over Single-Stack Components
Given architecture diversity, we standardized visual and interaction primitives first, allowing each product team to adopt the system regardless of framework constraints.
- Tokenized color, typography, spacing, and base semantics
- Cross-stack consistency without forced framework migration
- Stable foundation for long-term pattern harmonization
- 02
Buy Speed, Then Layer Customization
We used a third-party component base to avoid delaying roadmap execution, then customized patterns to align with product requirements and brand direction.
- Immediate support for in-flight greenfield delivery
- Reduced bootstrap cost for component development
- Focused effort on differentiating product workflows
- 03
Build in Parallel with Product Delivery
Rather than pausing delivery, we evolved the system incrementally while teams shipped, establishing standards through active use instead of isolated theory.
- Enabled practical feedback loops from live products
- Improved adoption through real project integration
- Balanced near-term shipping and long-term quality
- 04
Embed Accessibility as a Default
Accessibility was implemented as a system-level requirement through token contrast decisions, semantic-first components, and ARIA support where necessary.
- Contrast-aware token definitions
- Semantic HTML as component baseline
- Lower compliance risk through default-safe patterns
- 05
Treat the Design System as a Product
Governance, documentation, release operations, and roadmap ownership ensured the system could continue evolving beyond its first implementation phase.
- Cross-functional council and recurring reviews
- Dedicated Jira workflow for system backlog
- Living documentation and versioned package delivery
06 | Results
We transformed a collection of disconnected applications into a systemized platform experience teams could build and scale together.
- Adopted across seven applications, including five greenfield and two legacy products
- Reduced UI fragmentation and increased cross-product experience consistency
- Accelerated delivery through reusable patterns and shared implementation standards
- Improved design-engineering collaboration via a common language and workflow
- Increased accessibility consistency and reduced downstream compliance risk
- Established governance and tooling for continued long-term system evolution
07 | Reflection
What I Learned
What Worked
- A token-first approach made system adoption feasible across diverse technical environments
- Treating the system as a product created the governance needed for sustained progress
- Building in parallel with delivery improved adoption because standards were proven in real use
- Documentation and distribution discipline were as important as component design quality
- Embedding accessibility early reduced rework and improved confidence across teams
- After many naming debates and zero universally cool winners, we embraced the practical choice: Advarra Design System (ADS)
What I Would Improve
- Push earlier for dedicated system capacity at key scaling moments
- Expand implementation guidance for legacy migration playbooks
- Formalize adoption metrics and quality benchmarks sooner
- Increase enablement touchpoints for teams new to token-driven workflows
- Invest earlier in stronger contribution pathways for distributed teams
Let's Build Better Systems
If you need a design system that improves consistency without slowing delivery, let's connect.
Get in Touch