Mar–Sep 2025
Foundations → Rollout
Design system for global financial products
Problem context
Fragmented systems with unclear ownership
The portfolio had grown to four product surfaces, each with its own constraints. The flagship workflow platform handled complex multi-step processes for trading and compliance teams. The extension ecosystem let partners build on top of the platform. The developer portal and API console served integration teams. The model risk management app supported quantitative analysts reviewing model outputs.
The ecosystem already had shared building blocks: a web component framework, brand and content standards, and cross-product pattern libraries. But these assets did not add up to a mature, fully governed design system. They lacked the connective layer — shared tokens, interaction rules, state semantics, and a contribution model — that would make them function as one source of truth. Interaction behavior differed across products. Pattern coverage was uneven. The extension and developer surfaces still relied on a legacy system. Two style guides with slightly different palettes meant teams made local color and spacing decisions that compounded over time.
Ownership was split across platform, UI enablement, and product teams. Common patterns were rebuilt independently, risk increased in trading and compliance-adjacent workflows where consistent states and reviewability mattered, and scaling became harder as documentation fell behind. The opportunity was clear: create a system that could sit above the existing stack, unify behavior and standards, and become a single source of truth across products and teams.
Parallel work
Teams rebuilt the same elements independently.
Legacy system
Extensions and developer tools ran on an older DS.
Success criteria
One source of truth at scale
Success meant teams shipped faster because the system reduced repeated decisions and rebuilds, while baseline quality improved in regulated, data-dense workflows. We optimized for adoption first, then expanded coverage based on what teams rebuilt most often and what carried the most risk. Version 1 did not include a full rebrand, a complete migration of legacy surfaces, or tooling automation such as automated code modifications and quality checks.
How we measured it
Key decisions
From operating model to shipped components
Governance shipped with the system
Ownership was split across multiple teams, so the system needed a clear operating model from day one. I designed a lightweight governance loop covering intake, review, definition of done, and release communication. Teams could request additions, understand what belonged in the shared system versus their local codebase, and adopt changes on a predictable cadence.
This made governance practical rather than bureaucratic. It reduced ad hoc decisions, clarified contribution expectations, and improved coordination across design and engineering. Starting it early also made rollout more credible: pilot teams knew when the system was ready for new work, what quality bar each component had to meet, and how the team documented platform-specific exceptions instead of letting them turn into silent forks.
Intake
Clear criteria for what enters the design system.
Standardize the missing layer, not replace the stack
The organization already had a shared component framework, brand standards, and pattern libraries, so the goal was not to replace them. I treated those assets as the delivery layer and focused the system on what was missing: shared tokens, interaction rules, state semantics, and workflow patterns. Tokens became the connective layer between design intent, the two existing visual palettes, and implementation across products.
This reduced migration risk and helped teams align behavior without waiting for a full rebuild. It also reduced local overrides by giving teams one semantic model that could map into different product contexts without forking components. I worked with engineering to map tokens across four platform targets: React for web surfaces, Electron for the desktop workflow platform, Flutter for mobile, and a web-based SDK for partner extensions. Where platforms needed different behavior, we documented those differences explicitly so consistency did not collapse into a lowest-common-denominator solution.
High-cost patterns shipped with accessibility built in
Instead of trying to cover everything, I prioritized the patterns that were both expensive to rebuild and risky to get wrong: dense tables with inline editing and sorting, real-time status indicators, watchlists with streaming data, trade execution flows, and exception handling with audit-friendly outcomes. I worked with the product manager to sequence the pattern backlog by rebuild frequency and regulatory exposure. That kept the scope realistic for a team of six and made v1 useful on real product work, not just a reference library.
Each pattern shipped as a complete contract. States, keyboard behavior, focus management, WCAG 2.1 AA contrast, and ARIA semantics were part of the definition of done, not follow-up tickets. For dense workflow screens like data grids and review queues, that meant tab order, focus trapping, and screen reader announcements for state changes were tested before the pattern entered the library. Product teams got working, accessible behavior by default instead of retrofitting it during release hardening.
Adoption that teams could plan, not just react to
The system had to earn adoption, not require it. I chose the flagship workflow platform and the model risk management app as pilot surfaces because both teams were already rebuilding the same patterns and had the most to gain. The extension ecosystem followed with selected flows. The developer portal was deferred — it ran on a legacy system with high migration cost and lower urgency.
Adoption was incremental. Teams started with tokens, then moved to components, then to domain patterns at their own pace. Clear entry points, onboarding documentation, and a contribution flow meant teams could plan adoption into their sprint cycles instead of treating it as an interrupt.
Pilot selection
Started where the pain was highest, with the most rebuilds.
Outcomes
What shipped and what changed
By the end of the September rollout, v1 foundations and components were in active use across priority surfaces for new feature work.
Key outcomes
~180 tokens and ~35 core components in active use on priority surfaces, supporting two visual themes.
10–12 domain patterns standardized, replacing one-off implementations of dense tables, real-time states, and exception flows.
Faster UI delivery for adopting teams, since they composed screens from standardized patterns instead of rebuilding them each time.
Fewer late-stage regressions as components shipped with tested state semantics and accessibility.
Cross-platform consistency improved as teams referenced the same tokens and interaction specs instead of solving the same problems locally.
Retrospective
What I'd keep, change, and build next
The biggest win was grounding the system in real financial workflows. Dense tables, trade flows, and exception handling carry the most risk and cost the most to rebuild, so standardizing them made the system useful from day one. Governance was the other critical factor — without a clear intake, review, and release loop, the system would have fragmented again.
What I underestimated was migration friction. v1 focused on new feature work, which was the right call for adoption speed, but legacy surfaces kept drifting in the meantime. The developer portal and parts of the extension ecosystem still ran on the older system by September. I should have paired rollout with a migration guide and deprecation timeline, even if full migration was out of scope.
Closing that gap is the clear next step. Usage analytics would help spot adoption gaps and guide deprecations. Migration playbooks would reduce upgrade friction. As contributions grow, automated accessibility checks and visual regression testing would maintain quality without adding review overhead.
