Enterprise design-system evolution · 2016–2025
A design system is never finished. I built the operating program that helped Citrus keep evolving.
I first worked on Citrus as a UX Lead, driving strategy and documentation based on customer feedback. I partnered with an engineer to translate that strategy into a more modular foundation. Three years later, I took ownership of the system and began treating it as a product: building its roadmap, operating model, contribution paths, documentation, and cross-functional rhythm. Over the next six years, I helped lead Citrus through repeated architectural and design-language changes, culminating in the staged launch of a more composable generation in 2025.
- Role
- UX Lead · Product Design Manager · Engineering Manager · Senior Product Owner · Staff Design System Manager
- Scope
- System architecture · Product strategy · Roadmapping · Team leadership · Governance · Design language · Design tokens · Documentation · Contribution model · Release management · Adoption & enablement
- Timeframe
- 2016–2025
Two-minute summary
Citrus needed a reliable way to change, not another claim that the system was finished.
2016–2025
The starting point
The system had accumulated technical capability, but ownership, planning, documentation, contribution, release communication, and adoption support were uneven. Citrus needed to become governable and sustainable as shared enterprise infrastructure, well beyond the component work itself.
What I changed
I treated Citrus as a product and platform. I established roadmap and backlog discipline, strengthened design-engineering collaboration, improved documentation and contribution practices, created recurring stakeholder communication, managed delivery and support, and made the system’s priorities and tradeoffs more visible.
How the system evolved
That operating model allowed us to keep changing the technology underneath it. We moved through a major component and documentation reset, used Citrus to help carry a new design language in 2023, and then moved toward a more composable architecture with unified foundations, tokens, centralized Figma variables, and phased launch gates in 2024–2025.
My leadership range
Across the larger Citrus story, my role expanded from UX strategy and documentation into design management, engineering management, product ownership, program operations, and design-system leadership. Specialists retained ownership of their craft and implementation decisions; I connected customer feedback, design intent, product direction, and engineering work across the program.
The result
Citrus became more than a component library maintained by a core engineering group. It became a visible platform program with clearer ownership, governance, contribution, documentation, release expectations, and an architecture that could continue evolving with product needs.
The lesson
A durable design-system practice builds the product, governance, and operating structures that can carry the system beyond any one generation.
What I want a hiring leader to knowI have led a design system from early UX strategy and documentation through productization and multiple generations of change. I have operated across design, engineering leadership, product, people leadership, governance, release, and adoption—and built the program structures that kept the system moving as the organization changed.Continue to the full evolution
A decade of system evolution
Five eras. The same underlying responsibility: make change safer to adopt.
Citrus existed before I owned it. My relationship with it began in 2016 as a UX Lead, when customer feedback was exposing the adoption cost of a foundation still heavily dependent on a monolithic CSS model. I drove the strategy and documentation direction, then worked with an engineer who translated that strategy into a more modular approach. That gave me an early view of a recurring design-system problem: shared infrastructure creates leverage only when teams can adopt change without inheriting unnecessary risk.
By 2019, Citrus had stronger technical momentum, including modular styles and React components, but the program around the technology had not matured at the same rate. I was asked to take over the team while also leading Talent design, connecting product direction, design, engineering management, planning, and organizational adoption.
From there, the work became a multi-generation transformation rather than a single redesign.
2016
Modularize the foundation
Challenge
Citrus was still heavily dependent on a monolithic CSS model. A change could force consuming teams to take a much larger update than they needed, increasing regression risk and QA cost.
My contribution
- Led the strategy for evolving the foundation based on customer feedback and the adoption friction teams were experiencing.
- Worked with an engineer who translated that strategy into modular packages, separating slower-changing foundational styles from faster-changing component styles.
- Drove documentation improvements so teams could better understand what the system provided and how to use it.
- Connected customer needs, design intent, and adoption risk to early design-system decisions.
Why it mattered
This was my first lesson in design-system adoption: a technically correct shared system can still be expensive to consume. Architecture and distribution shape trust.
PatternAdoption begins with the cost of change.
2019
Productize the design system
Challenge
By 2019, Citrus had meaningful engineering investment and a growing component model, but the program lacked durable product direction, design leadership, planning, and operating visibility.
My role
I took over Citrus in February 2019 while still leading design for the Talent category. For a period, I operated across product direction, design management, and engineering management for a core team of approximately five engineers and one designer.
My contribution
- Re-established roadmap ownership and backlog discipline.
- Triaged product requests, support needs, defects, and platform work against shared priorities.
- Clarified acceptance practices and delivery expectations.
- Managed and supported the cross-functional team.
- Built recurring communication with product, design, engineering, and leadership partners.
- Reframed Citrus from a technical library into a product with consumers, priorities, tradeoffs, and an adoption journey.
Why it mattered
Durable ownership connected technical investment to organizational need and gave the program a clear center.
PatternShared infrastructure becomes a product when someone owns the whole journey—not only the artifact.
2020–2022
Build the program and evolve the architecture
Challenge
The first component generations had created consistency but also exposed limitations: inherited styles could create production conflicts, documentation was too engineering-centered, and the growing organization needed a clearer way to consume and contribute to the system.
My contribution
- Helped shape a documentation direction that better served designers and engineers.
- Established stronger intake, contribution, review, and support practices.
- Used recurring working sessions, contribution reviews, and roadshows to create shared context.
- Partnered with engineering on a more durable React-oriented component model while retaining paths for teams with different technical constraints.
- Managed the roadmap across planned platform work, defects, support demand, and changing organizational priorities.
- Connected system decisions to product needs rather than treating Citrus as an isolated technical initiative.
Why it mattered
Shipping components now depended on the surrounding capabilities required for an enterprise platform.
PatternThe system around the system determines whether the technical system can scale.
2023
Carry a new design language through the platform
Challenge
A significant UI refresh introduced a new visual language, and Citrus became one of the mechanisms for applying that direction across the product ecosystem. Its cohesion accelerated coordinated change but also revealed that future product innovation needed more flexible building blocks.
My contribution
- Helped sequence design-system work around the new design-language direction.
- Connected authored design intent to reusable production components and foundations.
- Coordinated design and engineering requirements as visual decisions moved into shared infrastructure.
- Managed the tension between near-term consistency and the longer-term need for greater composability.
- Helped shift the system toward shared building blocks that could support differentiated experiences without abandoning common foundations.
Why it mattered
This was the pivot between generations: preserve the leverage of standardization without letting standardization prevent evolution.
PatternA mature design system must know when consistency creates leverage—and when it prevents evolution.
2024–2025
Build and launch the next generation
Challenge
The next generation needed greater product flexibility while keeping design, engineering, accessibility, distribution, and release behavior coherent. The organization still depended on the existing system, so this could not be a single disruptive cutover.
My contribution
- Led the product and operating sequence for the generational modernization.
- Helped guide the move from larger, rigid components toward smaller, composable building blocks.
- Supported a unified token direction and centralized Figma variables across web and mobile needs.
- Partnered with engineering and design specialists on requirements, dependencies, and readiness.
- Reworked the release rhythm toward a monthly cycle with clearer planning, delivery, hardening, and communication stages.
- Formalized Alpha, Beta, and Official Launch gates and coordinated adoption support through shifting resources and priorities.
- Key launch milestones
- Alpha · June 27, 2024
- Beta · October 1, 2024
- Official Release · July 1, 2025
Why it mattered
The staged launch gave teams a credible way to understand, evaluate, and move toward the new generation.
PatternGenerational change succeeds when architecture, migration, communication, and trust move together.
Program building
The components changed. The program made repeated change possible.
Across the generations, my most durable contribution was building and operating the connective layer around the library. That layer turned specialist work into an enterprise capability.
Leadership principleI connected specialist decisions into a coherent product and made the tradeoffs visible enough for the organization to move. Specialists retained ownership of their craft and implementation.
Decision explorer
After years of standardization, how do you add flexibility without returning to fragmentation?
Open each option to compare its advantage and risk.
Option AKeep expanding opinionated components
- Advantage
- Preserves consistency and gives consuming teams highly complete solutions.
- Risk
- The system becomes increasingly rigid, forcing product needs into structures that no longer fit.
Option BLet product teams customize freely
- Advantage
- Maximizes local speed and flexibility.
- Risk
- Recreates duplicate solutions, inconsistent behavior, accessibility risk, and long-term maintenance cost.
Option CMove toward governed composability
- Advantage
- Gives teams smaller reusable primitives and shared foundations while retaining system-level standards.
- Risk
- Requires stronger documentation, governance, design judgment, and migration support; flexibility without operating discipline can still fragment.
Decision
Move toward governed composability.
The strategic direction was to evolve the architecture and operating model together: smaller building blocks, stronger shared foundations, and clearer governance, staged through release gates so consuming teams could learn and adapt without a single forced cutover.
My role in the decision: I translated the direction into product sequence: roadmap, requirements, dependencies, cross-functional decisions, release mechanics, readiness criteria, stakeholder communication, and adoption support. Engineering owned implementation depth; design, platform, accessibility, and product partners shaped the solution with me.
Scale & evidence
A program sustained across years, generations, and an enterprise product organization.
Evidence that can be stated confidently
- Worked on Citrus across 2016–2025, with continuous product and program ownership from 2019–2025.
- Led across product, design, and engineering-management responsibilities during the 2019 reset.
- Managed design-system vision, roadmap, backlog, governance, contribution, documentation, release, and rollout across multiple generations.
- Led the program sequence for Citrus 7 Alpha, Beta, and Official Launch.
- 2016Modular CSS strategy and documentation
- 2019Ownership reset
- 2020Architecture and documentation generation
- 2023New design language
- Jun 2024Alpha
- Oct 2024Beta
- Jul 2025Official Release
- Aug 20253,245-reference usage proxy
Verified usage proxy
3313,245
Internal distribution references · September 2024 to August 2025
Four perspectives
The system had to survive four definitions of success.
Executive
Need
Shared UI infrastructure that could support a growing multi-product organization without becoming a bottleneck.
My contribution
Made priorities, investment choices, risks, dependencies, and rollout decisions visible enough to evaluate and support.
Product
Need
Reusable capability without preventing teams from solving distinct customer problems.
My contribution
Connected roadmap, intake, contribution, and migration decisions to product outcomes and constraints.
Design
Need
A design language that could remain coherent from authored intent through reusable production behavior.
My contribution
Connected shared foundations, variables, review practices, documentation, and component direction across design and engineering.
Engineering
Need
A platform that could evolve without destabilizing consuming applications or multiplying bespoke forks.
My contribution
Partnered on requirements and sequencing, surfaced distribution constraints, coordinated release gates, and created more predictable stabilization and communication rhythms.
What became possible
The result was a system better equipped to keep changing.
Citrus had durable product ownership. Shared UI infrastructure could be managed through strategy, roadmap, priorities, and explicit tradeoffs.
The core team had an operating model. Intake, contribution, review, documentation, release, support, and stakeholder communication became parts of the product rather than informal side work.
Design and engineering had a stronger coordination layer. System decisions could move between design intent, implementation constraints, product needs, and platform dependencies with clearer ownership.
The architecture could evolve across generations. The program moved from modularizing a monolithic foundation, through cohesive component generations, toward more flexible and composable building blocks.
A new design language could travel through shared infrastructure. Citrus became a mechanism for carrying broad experience change rather than a static library detached from product direction.
Generational rollout became explicit. Alpha, Beta, and Official Launch stages created shared readiness language and a more legible migration path.
Adoption could be observed rather than assumed. Usage signals provided a starting point for understanding consumption while exposing the need for a stronger measurement model.
Reflection
What nearly a decade around one design system taught me
Fund enablement as product work
Documentation, migration guidance, support, deprecation, roadshows, and adoption measurement are not launch follow-ups. They are part of the platform and need capacity alongside implementation.
Define the measurement model before the generation ships
Package and reference counts were useful consumption signals, but a stronger model would connect technical usage to repo-to-team mapping, migration status, support demand, quality signals, accessibility, and qualitative confidence.
Make decision rights explicit before pressure arrives
Architectural, design-language, product, accessibility, and platform decisions often overlap. Clear decision rights reduce delay and make tradeoffs easier to revisit when priorities change.
Treat contribution as a product journey
Teams need a clear entry point, readiness criteria, ownership, support, review expectations, documentation, and predictable outcomes. Contribution cannot depend on knowing the right person on the core team.
Design for the next generation
The design system itself must be designed for replacement and evolution. A generation that is difficult to change eventually turns yesterday’s consistency into tomorrow’s constraint.
Role-fit bridge
What this story demonstrates
- Long-horizon enterprise design-system leadership
- Product ownership of shared infrastructure
- Leadership across design, engineering, and product functions
- Program building from ambiguous ownership to durable operating model
- Team and people leadership
- Roadmap, backlog, requirements, and dependency management
- Design-engineering-product translation
- Governance and contribution-model design
- Documentation, enablement, adoption, and change management
- Design-language and component-generation transitions
- Technical fluency without overstating implementation ownership
- Release strategy across Alpha, Beta, and production launch
- Evidence-aware decision making
- Ability to sustain a platform through organizational and strategic change
I’m proudest of the leadership and operating structures that allowed Citrus to keep changing beyond any one generation.