Carlyle · Lead UX · 2025–2026
The schema was the interface. So the analysts worked in Excel.
A schema-first MVP made the data model the thing users had to navigate. Analysts left the platform every time the math required a cross-vertical read, recalculated in Excel, and imported the answer back. The redesign rebuilt the product around three analyst roles instead of one data model, and the design system underneath it moved its source of truth out of Figma and into the production repo.
The problem
When the data model is the navigation, every real question is a detour
The MVP had been built outward from the schema. Entities in the database became sections in the product, and the shape a user had to hold in their head to get anything done was the shape of the tables underneath. That is a fast way to ship a first version and a slow way to do investment work.
The break showed up wherever the work crossed a boundary the schema did not. An analyst pulling numbers that lived in different verticals had no place in the product to put them together, and no check to tell them the combination was wrong. So they exported. They rebuilt the calculation in Excel, where the cross-vertical read was possible and the error checking was their own attention, and imported the result back as a fact the platform then treated as authoritative.
The workaround was the bottleneck. Not the slowest screen, not a missing feature: an entire second tool the product had quietly made mandatory, sitting in the middle of the workflow with no audit trail and no validation.
Why the obvious fix fails
The obvious fix is to port the spreadsheet. Build a grid in the app, put the formulas in it, call the loop closed. It fails for the reason the loop existed: the spreadsheet was never the requirement. The requirement was a place where numbers from different verticals could be read together and checked. Porting the grid reproduces the schema problem one layer up, and hands the analyst a worse Excel.
The second obvious fix is a redesign of the screens. It fails earlier. If the navigation is the schema, no amount of screen work changes what the user has to understand to move.
The insight
There was never one analyst
The platform had one user model: analyst. The work had three. An entry analyst is assembling and inputting. A senior analyst is checking, interpreting across verticals, and deciding what is wrong. Leadership is reviewing and approving, and needs to see the shape of a decision without rebuilding it.
Those are three different jobs standing on the same rows, and a schema-shaped interface serves none of them, because it is organized around what the data is rather than what any of them is doing.
So the information architecture was rewritten around the three roles, and each tier got a workflow tuned to the decisions that role actually makes. That is the whole reframe. Everything downstream — which Excel behaviors got absorbed, where error checking had to sit, where AI could carry the math — falls out of it.
Schema as navigation → three role-shaped workflows → the cross-vertical read happens in-platform → errors surface inside the work, not after it → AI assists the calculation and the interpretation → the export loop has nothing left to do
Scope
What I led
- UX strategy, new experience design, and legacy modernization across the platform. Senior execs and analyst teams as the primary users.
- Information architecture rewrite. From schema-first to role-first: organized around how analysts move through approvals, reviews, and decisions, not how the data model is structured underneath.
- Scalable workflows across approvals, reporting, reviews, handoffs, dashboards, collaboration, permissions, and audit history. Each one absorbed a piece of the Excel-export-recalculate-reimport loop into the platform.
- Real-time error checking inside the workflow, so analysts caught calculation problems before they propagated. AI assistance on cross-vertical data interpretation and the calculations Excel used to run.
- The platform’s design system, built as a modular token base and carried across two product generations — V1 and a ground-up V2.
- AI-assisted design and development workflow established as a repeatable practice for the team. Tightened the loop between design and engineering and reduced time-to-delivery.
Embedded on the product team for the full engagement, partnered with PMs, stakeholders, and engineering in Agile. The system had named consumers: three front-end engineers, backend engineers working in the front end, and a product designer building against it.
The system
A token factory, not a component catalog
A full enterprise design system for the platform, built from the foundation up. React and TypeScript on a Material-UI base, with deep overrides so every component matched the product’s voice rather than reading as MUI default.
The base layer is the part worth arguing about. Rather than a flat catalog of components, the system is a modular token base — a token factory that two teams and two product generations composed against. Modules and pages get assembled per user need instead of rebuilt, which is the only reason a ground-up V2 could stand on the same foundation as V1 rather than starting over.
The source of truth moved out of Figma
Tokens are authored as JSON in the production repository and mirrored 1:1 into Figma. Not the other way around. The library designers consume and the library engineers ship are the same library, so there is no translation step where the two can quietly diverge.
This is a real trade and it is worth naming the price: it puts the design canvas downstream of the build, and it asks a designer to accept that the repo wins an argument about a value. What it buys is that drift becomes structurally impossible rather than something a quarterly audit catches after six months of it.
Documentation as the thing consumers actually work from
The whole system is documented in Storybook as the single source: token structures, every component, usage guidelines, and do’s and don’ts. The goal was specific — engineers and designers build correctly without routing through me. A design system whose author is the API is not a system, it is a bottleneck with a component library attached.
Intake and release discipline
New components had to justify use case and impact before entering the system, so the library grew on evidence rather than on request volume. Breaking changes were gated behind testing and release review; refactors shipped only once verified against the teams consuming them.
Both of those are deliberately unpopular. An intake gate means telling a teammate under deadline that their component is not going in yet, and a release gate means a refactor waits. The alternative is the failure mode every long-lived system has: a catalog that grows faster than its consumers can absorb, and a breaking change that lands on three engineers who did not know it was coming.
Accessibility was a component requirement rather than a review gate — a component was not done until it met WCAG, which is a cheaper place to pay for it than a remediation pass at the end.
The constraint
Confidential by design, and what that costs this page
The product, the screens, the data, and the team are under NDA. No visuals appear here because none have been cleared, and I am not going to fabricate them. Neither a blurred screenshot nor a “representative” redraw is an honest artifact; both are a picture of something that does not exist, presented where evidence should be.
State the cost plainly. Every other case study on this site can be checked. Grimoire and Ascend were audited claim-by-claim against their own codebases, and the audits are what corrected them. This page cannot be audited that way by a reader. The mechanism is public — role-shaped workflows replacing a schema-shaped one, the Excel loop absorbed in-app, error checking moved inside the work, a token base in the repo with Figma mirroring it — and the specifics are not.
What that means for a reader weighing this page: treat the architecture claims as verifiable in conversation and not on the page. The fastest route to confidence is thirty minutes and specific questions.
One consequence worth stating rather than hiding: an earlier version of this page and of my resume carried a task-completion multiplier for the redesigned workflows. It came out during an accuracy pass, because I could not source it to a measurement I could describe. It may well have been true. It was not something I could stand behind at the standard the rest of this site is held to, so it is gone rather than softened.
The deeper read
The full version, on a call
The friction map from the pre-redesign analyst flow. What distinguishes the entry, senior, and leadership workflows once you get past the labels. The calls on which Excel features to absorb into the app and which to remove from the workflow entirely. Where AI assistance on the math helped and where it had to step back. The token-and-override architecture that let MUI carry weight without dictating the look. How intake actually ran when a team was under deadline. And what I would do differently, which is the part that does not compress well into a paragraph.
What this proves
On Carlyle
This is the case where the reframe happened inside somebody else’s organization, on somebody else’s roadmap, with named engineers downstream of every decision. The product was built around a data model; the work was three different jobs. Changing which of those the interface is organized around is the whole engagement, and everything else — the absorbed Excel loop, the in-flow error checking, the AI on the math — is a consequence of getting that one thing right.
The design system is the other half of the proof. A token base in the production repo, mirrored into Figma, documented in Storybook, gated at intake and at release, composed against by two teams across two product generations. That is design systems as governance rather than as a component library, and it is the part of this engagement that outlived any individual screen.