Uplift: Fixing the Org Before Fixing the Design System

The moment it clicked

There’s a pattern I’ve learned to recognize — and it doesn’t announce itself clearly at first. You ask a developer why they built a custom component instead of using the design system, and the answer is usually something vague: “the system didn’t have what we needed,” or “it was faster to just build it.” What they almost never say directly is: I stopped trusting it.

That’s what was happening at TVH when I arrived. Uplift existed — a real, thoughtfully constructed system built on MUI with a Figma component library designed to give designers and developers a common visual language. But when I started looking at what was actually being used in production, I kept finding components that didn’t exist in the library. Custom builds. Parallel solutions. The quiet evidence of a system people had quietly walked away from. Only one development team was using the coded system at all — and even they were doing it largely unguided by UX, without the design intent behind the components fully communicating across the handoff.

What made this more than a tooling problem was the strategic context I was stepping into. TVH is a multi-brand, international operation: the main TVH brand serving western Europe, TVH America covering North America, and Bepco — primarily agricultural, based in France. Each brand had its own experience, its own technology, its own product offerings. The company’s direction was to bring them together — a cautious but deliberate consolidation toward a single platform for buying industrial parts internationally. That meant the design system wasn’t just infrastructure for today’s products. It was the foundation that would make a major corporate strategic move possible. And right now, it was a tool one team used, inconsistently, without guidance.

The diagnosis

The answer, once I found it, was structural — not a design quality problem, not a documentation problem, not a communication problem. It was a capacity problem.

Design system engineers were embedded within the Development organization. In theory, this made sense: they were writing code, they belonged with the engineers. In practice, it meant their time was perpetually at risk. When a product sprint got tight — and product sprints always get tight — the design system work got deprioritized. The engineers who were supposed to maintain Uplift’s repository, address bugs, and keep the Figma library synchronized with production code were reassigned. Not once. Consistently. This was the default behavior of a system where design system work had no protected capacity.

The compounding effect was predictable. When a developer found a bug in an Uplift component and submitted it, nothing happened — or nothing happened fast enough. When a designer updated a component in Figma, there was no guarantee the code version would follow. The Figma library and the codebase drifted. Teams discovered the drift when it caused problems in delivery. They learned, correctly, that using Uplift introduced risk. So they stopped using it.

There were real handoff friction points layered on top of this. Developers needed Figma access to understand design intent — but that meant designers had to be more rigorous about finalizing and handing off documented designs before developers opened the file. Any ambiguity in the Figma file became a translation risk: without reliable design tokens in the system, developers were using eyedroppers to sample colors and estimating spacing values. The result was subtle inconsistency — not catastrophically wrong, but wrong enough to accumulate into a product that didn’t look quite like what design had specified.

The multi-brand complexity amplified everything. TVH, TVH America, and Bepco each had distinct experiences, technology stacks, and product offerings. A design system capable of serving that complexity — let alone the planned consolidation toward a single international platform — required real architectural thought and sustained engineering attention. Without protected capacity, the scope became a liability.

What had to be true for the system to work: the engineers maintaining Uplift needed to be insulated from the competing demands of product delivery. That protection couldn’t be informal. It needed to be organizational.

The vision

My argument to engineering leadership was straightforward, even if the conversation wasn’t easy: the design system isn’t a development project that occasionally needs UX input. It is a UX project that happens to produce code. Its primary purpose is to maintain the shared visual language between design and engineering — which means its health is fundamentally a design concern, not a delivery concern.

I framed it in the language that mattered to tech leadership at TVH: quality and performance. Those were the benchmarks they cared about, the metrics by which engineering success was measured. A design system that teams had opted out of was producing quality problems — subtle inconsistency, translation drift, components built in isolation rather than against shared standards. It was also creating velocity drag: every custom component built outside the system was engineering time that didn’t have to be spent. Uplift, if it worked, was a performance accelerant. If it didn’t work, it was overhead without benefit.

The deeper argument, though, was strategic. TVH was moving — carefully, deliberately — toward consolidating three distinct brand experiences into a single international platform. TVH, TVH America, and Bepco were each different in experience, technology, and market. Merging them wasn’t just a design challenge; it required shared infrastructure at the component level. We had already started templatizing the ecommerce sites across brands — making the experience and tech consistent while maintaining distinct brand identities through token-driven theming. That templatization only worked if the design system was mature enough to carry the weight. I pushed to mature Uplift quickly because I could see what it needed to become, and the window for doing so was not unlimited.

The approach

Once the engineers were under UX, the repository stabilized almost immediately. That part was the straightforward result of having protected capacity — work could be planned, bugs could be addressed, the Figma library and the codebase could be kept synchronized. The structural change was the unlock.

The harder and more interesting work was governance. Stability wasn’t enough to rebuild trust — we needed a model that gave teams a path to participate in the system rather than just consume it. The governance process combined three elements: a contribution model that let product teams propose new components, a review and approval process before anything shipped to the shared library, and documentation standards that made the system navigable for both designers and engineers.

The toolchain we built around Uplift reflected the different audiences who needed to use it. Storybook served as the developer reference — living documentation of components in their actual coded state. Zeroheight handled non-developer documentation, giving product, marketing, and other teams a readable reference that didn’t require opening a code repository. Marketing leveraged the system for non-ecommerce site design from Zeroheight directly, which extended Uplift’s reach beyond the product teams without creating a parallel system. Tokens Studio managed design token JSON as the source of truth, keeping the token definitions stable and portable across contexts. Figma Libraries served UX design, with the component library as the design-side expression of the same system engineers were building against.

The multi-brand challenge was handled through scoping — primary brand governed and stable first, secondary brands documented with a clear path into the system incrementally. It was an honest acknowledgment of capacity and leverage. Trying to solve for all three brands simultaneously would have diluted the effort enough to stall the trust recovery on the primary product.

At a certain point I recognized a tension building: the design system work was mature enough to need dedicated ownership, and the UX research and team leadership work was scaling in ways that made splitting my attention between them untenable. I hired a dedicated DS Design Lead to own and grow the system — someone who could carry Uplift’s ongoing maturity while I moved focus to the larger UX research effort and leading a team of six designers internationally. That transition was the proof that the system had genuinely stabilized: it could be handed off, and it would hold.

Building credibility

Getting the DS engineers to report through me took about six months — and most of that time wasn’t spent arguing. It was spent finding the right person to argue with.

TVH has a large, mature tech organization, and I was leading a peer org. UX didn’t traditionally have front-end engineers on its teams. That made the headcount ask genuinely unusual — not hostile territory, but unfamiliar territory. The risk wasn’t that engineering leadership would say no outright. It was that the idea would sit politely in a queue of things that might happen someday.

What broke it open was finding an engineering leader who understood what I was trying to do and was willing to champion it internally. That took persistent conversation and patience. But once I had that person, something more valuable happened: they didn’t just advocate for the move, they pushed back on how I was planning to run it. Their feedback — on the governance structure, on how contribution workflows would interact with engineering review processes, on what “stable” actually meant from an engineering point of view — made the model significantly stronger. It wasn’t a design system governance process designed by UX and handed to engineers. It was a process that had been stress-tested by someone who understood both sides.

That engineering credibility mattered enormously for adoption. When other development teams saw that the governance model had engineering fingerprints on it — that it wasn’t just a fancy design tool with a new reporting line — the conversation changed. The system had standing in tech because tech had helped shape it.

What shipped

By the time I left TVH, Uplift had gone from one development team using the coded system — mostly without UX guidance — to four brand tech teams actively using it: all three of our main brand tech teams plus our secondary brand team. That’s 15 front-end developers building against the same system, with design intent communicating reliably across the handoff.

The token architecture was probably the most concrete day-to-day improvement for developers. Before stable tokens, developers were using eyedroppers to sample colors from design files and estimating spacing values. That sounds minor until you see it compound across hundreds of components and dozens of pages — subtle inconsistency that no single person caused and no single person could fix. With mature design tokens and Figma Dev Mode, developers could extract consistent CSS directly from the design file. The guesswork left the process.

• DS engineers with protected capacity under UX, insulated from product delivery reprioritization
• Stable Uplift repository with active maintenance: bugs addressed, Figma library kept synchronized with production code
• Mature design token architecture enabling CSS extraction from Figma Dev Mode — eliminating eyedropper sampling and spacing estimation
• Three-layer governance model: contribution process, engineering review/approval gate, documentation standards — co-designed with an engineering advocate
• Templatized ecommerce sites across brands: consistent experience and tech with token-driven brand theming
• 4 brand tech teams adopted (3 primary + 1 secondary), reaching 15 front-end developers
• Developers contributing to the system rather than working around it

The multi-brand work was scoped honestly. TVH’s direction was consolidation, but the process was cautious — we weren’t merging three distinct brand experiences overnight. What we could do was build the shared architecture that made future consolidation viable: templatizing the sites, stabilizing the token system, and establishing the governance model that would scale as more brands came in.

The larger argument

The lesson I’d take from Uplift to any organization with a struggling design system: before you invest in better documentation, better tooling, or better design quality, ask where the engineers are. Not which engineers — where they sit. Who sets their priorities. What happens to their backlog when a product sprint gets tight.

A design system is infrastructure. Infrastructure requires protected maintenance capacity. When that capacity is embedded in a delivery organization, it will always lose to delivery pressure — not because anyone made a bad decision, but because delivery pressure is immediate and visible in ways that infrastructure debt isn’t. Teams will consistently make the locally rational choice until the accumulated cost becomes impossible to ignore. By then, the trust is already gone.

What the Uplift work taught me is that a design system’s value is inseparable from its governance structure — and its governance structure is inseparable from its place in the org chart. The system I inherited wasn’t bad work. It was good work that had been structurally set up to fail. Fixing it meant fixing the structure first.

The strategic dimension is what I find most interesting in retrospect. At the time, the day-to-day work was maintenance, adoption, and governance. But the reason it mattered — the reason I pushed to mature the system as quickly as we did — was the corporate direction TVH was moving. Consolidating three international brands into a single platform isn’t primarily a technology challenge. It’s a design language challenge. A component system that works for one brand in one market can’t carry that weight. A design system with mature token architecture, proven multi-brand theming, and engineering credibility across the organization can. We were building the foundation for a move the company hadn’t fully committed to making yet.

That’s the kind of infrastructure investment that requires someone in UX to see forward — to understand that the design system isn’t just about today’s product, but about what the organization is trying to become.