Reviving a stalled design system — and making the case to scale it

MX powers financial experiences like account aggregation, money management, insights, dashboards, and connectivity widgets, embedded across banks and credit unions and used by millions. Every client can theme those products to their own brand, and the same experiences span both web and mobile.

That makes a shared, consistent UI system not a nicety but the only way to ship branded, accessible products at scale without rebuilding them for every client. MX's design system, MXUI, is built on MUI (Material UI) with a theme wrapper that carries MX's look and feel.

When I took it on, the system was stalled. The team that had built MX's original in-house component library was gone, and the move to an MUI-based system had lost momentum. A few front-end engineers contributed on the side, but there was no dedicated owner, no plan, and no priority.

The contribution model wasn't holding. Under delivery pressure, design-system work was the first thing cut, along with tech debt, design debt, and even QA. A year in, only about a third of the code had migrated, and components from the old, unmaintained system were still shipping in products three-plus years later.

Meanwhile the stakes were rising. The mobile team was rebuilding the app and wanted it to scale, but every client still got a custom build, and the embedded web widgets and the native mobile UI didn't speak the same visual language.

My design-systems experience was why they handed it to me, and the first job was simply to give the effort a backbone. I stepped in as the de facto lead and PM for a scrappy, cross-functional group, running weekly working sessions, standing up a Jira board, and documenting decisions so the work had structure and memory instead of living in one recurring meeting.

Then I restructured the system itself around a few decisions:

• Lean on the framework, not against it. Wherever MUI's defaults were good enough, we used them rather than maintain custom equivalents, leaning on its color-token system, its components, and even interaction details like button ripple. We kept MX's look and feel through theming and built only the few custom components MUI couldn't cover.
• Rebuild the source of truth. I rebuilt the entire system in Figma on a MUI template, themed to match MX's existing design language, so design and code finally shared one foundation.
• Make the gap visible. I audited what had actually been customized in code versus what hadn't, and turned the differences into a tracked backlog.

The throughline was tokens. Treating color, type, and radius as named tokens, a single source of truth, means a change in one place cascades across every component, platform, and theme.

None of it mattered without priority, and priority was the hard part. Pitching the system on its own merits (accessibility, velocity, and consistency) hadn't moved leadership; those are easy to nod at and defer.

So I reframed it. The mobile rebuild's entire vision depended on scalable theming, and because the mobile app embeds MX's web widgets, the two have to speak the same theming language. A tokenized system is what makes that possible. Define a client's theme once, and it flows across every product and surface. I made the design system the means to an outcome leadership already wanted, not a virtue to be admired.

And I didn't just write it up. I built the case as something leadership could see and react to, with the stakes, the architecture, and the path, plus a working proof of concept of how easily themes could be swapped, supporting mockups, and a prototype of a longer-term portal where clients could customize their own theme. I presented it, and the work became a priority.

There was an important limit to the mandate. Teams were required to migrate onto MXUI, to stop using the legacy system, but not to make every component match the Figma designs. In practice they pull in MUI's defaults carrying our colors, radii, and typography styles through tokens, which is enough to count as “on MXUI.” But without the engineering time to refine components to spec, products drift toward a default look and away from MX's full brand and feel.

Closing that gap is the part I took on directly. With no dedicated engineers for it, I started writing the code myself, merging pull requests to bring components up to the Figma source of truth, both net-new and customized ones, week by week.

Designing the system and then implementing it in code keeps the foundation honest. The Figma library and the shipped components stay in lockstep, and I catch the gaps that only show up once a component is real.

The headline outcome isn't a metric yet. It's a mandate. An effort that had no owner, no plan, and no priority is now a leadership-backed initiative with a clear architecture, a tracked path, and a migration moving in code.

And it compounds. The system underpins MX's product suite of web and mobile experiences used by 9–13M+ people monthly, across a product organization of 9 designers and about 50 front-end engineers, so every component migrated and every product adopted widens the impact.

The biggest lesson, for me, was the importance of creating a vision. I didn't sell leadership on the design system. I sold them on what it would get them, tied to an outcome they already wanted. And I didn't just tell them; I showed them, with a working proof of concept and a prototype they could try for themselves.

I also learned how to lead without authority or resources. Bring order first with a board, a cadence, and documentation, then make the gaps visible and keep shipping, even when that means writing the code yourself.