How I led a large and diverse portfolio of enterprise products
into a unified, accessible and modern product suite
At symplr, I led the team towards transforming an eclectic set of legacy products into a more unified, modern, and accessible product suite—using a flexible, adoption-driven design system strategy that balanced business realities with long-term experience goals.
Role: UX Design Leader
Scope: 20+ legacy and net-new products
Focus: Design system adoption + product unification
Context: Conflicting product roadmaps, high customer risk, low UI/UX consistency
Impact: Drove widespread adoption of a design system, improving product cohesion, scalability, customer experience and sales demos.
Main Stakeholders: CPO, Platform, Product Leaders and Product Managers, Engineering Leadership and Engineers, and Marketing
-
A unified product experience was a business priority—but not an easy one to deliver.ription text goes here
-
symplr’s product ecosystem had grown organically over time:
Many legacy products with inconsistent UX patterns
Disjointed UI, branding, and interaction models
Varying levels of accessibility and technical maturity
The business set a clear goal: Create a more modern, unified product suite
This wasn’t just about aesthetic, it was critical to:
Reduce customer churn
Retain large enterprise customers
Win new, high-value deals
However, each product operated independently:
Each had its own roadmap and priorities
Many were already committed to customer-specific deliverables
Some were at risk of losing major customers if near-term features weren’t delivered
This created a fundamental tension:
Unification was a priority—but not always the immediate priority for individual product teams. text goes here
-
This wasn’t just a design systems challenge—it was a business alignment problem.
Conflicting priorities across products
While the organization wanted unified products, individual teams were focused on:
Customer commitments
Revenue-driving features
Churn prevention
Design system adoption often wasn’t in their near-term roadmap.
2. Risk of customer churn and lost revenue
Some products:
Needed to deliver specific features to retain large customers
Had made commitments to new enterprise clients
Forcing full adoption could have:
Delayed critical features
Put revenue and relationships at risk
3. Inconsistent Product Experiences
Customers using multiple symplr products experienced:
Different navigation patterns
Inconsistent workflows (create, read, update, delete)
Varying UI and interaction models
This increased friction and reduced overall product satisfaction.
-
20+ products with independent roadmaps
High stakes tied to customer retention and sales
Limited engineering capacity across teams
No single moment where all products could “pause” for adoption
Need to balance short-term revenue with long-term experience
We needed to unify the experience—without disrupting the business.
-
I reframed the approach: Design system adoption could not be a mandate, it had to be flexible, incremental, and aligned to business reality.
Instead of pushing for full adoption across all products at once, I focused on:
Making adoption easy
Enabling progress over perfection
Creating visible wins to build momentum
Progress toward adoption was more valuable than forcing full adoption at the cost of revenue or customer trust on broken commitments.
Ann (Director, Product Management) and Joey (Director, Engineering):
Hey Jen, do you have a designer who can help with the front-end rewrite on the Payer Product? Payer customers are complaining about the crashing and timeouts.
Jen: Hi there! When do you need the re-write complete?
Ann: ASAP. We are at risk of losing a few BIG customers.
Jen: I recommend building it using our design system so we have a modern, intuitive, and accessible product experience that incorporates the new symplr theming.
I can send you information on how the Compliance team adopted the system and reduced design and development time by 50%.
Edvard has capacity to help guide the design for the next few months before jumping over to help another team. Any concerns?
Ann and Joey: Sold!
Key decisions
-
I identified a product team that was already planning a full front-end rewrite.
This created the ideal opportunity to:
Fully adopt the design system end-to-end
Validate scalability and feasibility
We supported the team by:
Providing hands-on guidance
Mocking up fully adopted screens
Partnering closely with engineering
Outcome:
Achieved full adoption in a less than a year (team shipped once a quarter)
Reduced development time by ~50% due to reusable components
Created a tangible example of success
Why: Proving value in practice was more effective than enforcing compliance
-
The pilot team became a powerful advocate:
Shared wins across the organization
Demonstrated speed, scalability, and quality improvements
Helped other teams visualize what “great” looked like
Why: Teams are more likely to adopt when they see proven results from peers
-
For teams that couldn’t fully adopt due to roadmap constraints, we introduced phased adoption levels.
Instead of all-or-nothing, teams could adopt incrementally:
Level 1: Colors and fonts
Level 2: Logo, header, footer and menus
Level 3: Simple form elements
Level 4: Modals, toasts alerts
Level 5: Grids/data tables
Level 6: Complex form inputs
Design supported each level by:
Showing what screens looked like with each level applied
Guiding product and engineering teams through implementation
Why: Lowering the barrier to entry made adoption achievable within existing roadmaps
-
Rather than competing with product roadmaps, I aligned with them:
Teams with capacity → full adoption
Teams with constraints → incremental adoption
Teams with high customer risk → delayed but planned adoption
Why: Adoption needed to support—not disrupt—revenue and retention goals
-
As adoption increased, we focused on standardizing:
Navigation structures
Core workflows (create, read, update, delete)
Data entry and reporting patterns
Login and onboarding experiences
Why: Consistency across key interactions delivers high value to customers description
-
I balanced long-term vision with short-term constraints:
Reframed adoption from mandate → flexible system
Partnered closely with product management and engineering leaders
Identified opportunities for full vs. partial adoption
Created clear visuals to guide implementation
Built momentum through early wins and storytelling
Ensured continuous progress across all products
This allowed us to move toward unification—without halting delivery.
-
Adoption Progress during my 3.5 years at symplr:
~10 products fully adopted
~9 products ~70% adopted
~6 products ~30% adopted
Even partial adoption created a noticeable shift.
All products began to feel like part of the same family.
-
More modern, consistent UI across the suite
Improved accessibility and scalability
Faster development through reusable components
-
As adoption increased, the experience significantly improved:
Consistent navigation across products
Standardized workflows (create, read, update, delete)
Unified data entry and reporting experiences
Reduced friction for customers using multiple products
Accessible experiences for all abilities
This was especially impactful for enterprise customers using multiple symplr solutions.
-
A unified product ecosystem without disrupting delivery
Faster, more scalable product development
Improved customer retention and satisfaction
Stronger foundation for future innovation
Consistent and seamless sales demos to enable more closed deals
-
Driving large-scale system adoption in complex environments
Balancing business constraints with long-term vision
Influencing without authority through strategy and outcomes
Turning fragmented products into a cohesive experience
Building momentum through progress—not mandates
Tips for driving adoption
-
Explore what concerns or barriers are preventing adoption so stakeholders feel genuinely heard, then identify where you can reduce friction, provide clarity, or make the path forward easier
-
Pilot system adoption with one product first, and share measurable wins broadly
-
Show what’s in it for your stakeholders: faster delivery speed over time, accessible and usable components that support compliance and help win more deals, and clear ROI (build once, update globally with the flip of a switch)
-
When technical constraints exist, offer flexible or phased approaches (e.g., match themes first, implement full components later)
-
Align on adoption timelines (if business-mandated) and share transparent reporting to celebrate progress and build momentum across teams
Biggest takeaway:
By making adoption flexible and focusing on progress, we were able to unify a complex product ecosystem while improving both business outcomes and customer experience—proving that consistency at scale doesn’t require perfection, just momentum.