Product Design
Nadia Burger
Jul 28, 2026
Summary
At a B2B enterprise fintech SaaS company with 20 years of engineer-led design decisions, I diagnosed why the recent AI-assisted feature suite kept drifting visually inconsistent and architected a semantic token system to fix it at the root. With a two-person design team whose priority is feature delivery, execution is happening in the gaps between deadlines. This is a system being built, not a finished one.
The Challenge
The company's most recent features had been built using AI-assisted development and had drifted into visible inconsistency: two different button styles on one screen, AI-only purple showing up where it shouldn't, chips rendered as squares instead of pills, page backgrounds shifting shade from tool to tool. This wasn't sloppiness. It was the natural result of a design system that had primitive color values and Figma components, but no semantic layer connecting brand intent to what engineers, or AI tools, actually built.
That gap was about to matter more, not less. As the team started leaning on AI-assisted development with tools like Cursor, I recognized that the quality of AI-generated UI is directly capped by the quality of the design system feeding it. Without a semantic instruction layer, Cursor has no reliable way to know which token to reach for, third-party defaults from Tailwind and shadcn leak through uncorrected, and every Tailwind or shadcn upgrade risks a visual regression nobody planned for. With only two designers and feature work as the standing priority, this was never going to get fixed by working screen by screen. It needed an architectural fix that could hold even when nobody had spare hours.
My Process
I started with a gap analysis across three layers:
what existed in Figma (untokenized Tailwind UI kit components, mixed with components from the legacy design system using only primitive tokens)
what existed in code (primitive tokens and Tailwind utility classes, but no semantic bridge to the component layer), and
where AI tooling sat in between
In parallel, I audited six features against the absence of any documented UX standard, cataloguing concrete inconsistencies screen by screen.
From that audit, I identified the 6 components that if standardized would create the most coherence, and derived 15 explicit UX principles across five categories (actions and buttons, status and feedback, forms and inputs, tables and data, and AI-specific states), turning what had been implicit UX knowledge into something documented and enforceable regardless of who's doing the building.
Given the capacity reality, I made a deliberate call: architect the token chain and the workflow myself, then treat every component as an opportunity to prove the pattern rather than trying to rebuild the whole suite. The button component became that first proof point, built as a reference for how every future component should be structured, not as a one-off fix.
Solution (in progress)
The core piece already architected is a semantic token layer sitting between the company's primitive tokens and the third-party systems (Tailwind, shadcn) the product depends on. Instead of components and AI tooling reaching directly into raw hex values or utility classes, everything routes through named, intent-based tokens, for example, a button's background resolves through a documented chain rather than a hardcoded color. This is the piece that, once fully wired through, lets Cursor generate the right token consistently without hand-correction, and turns a future Tailwind or shadcn upgrade into a non-event instead of a regression risk.
Given our constrained capacity, I had to take an MPV approach. I audited the features and identified the 6 components creating the most visual drift and then prioritized building those out in order to create an immediate improvement in coherence.
Above: The Dashboard of the back-end system
Impact
It's too early to claim a measured before/after on rework rate or QA bug counts, and I'm not going to manufacture one. What I can point to honestly: the two shipped reference components and six fixes are working proof that the architecture holds under real use, not just in a slide deck. The audit itself already reframed the conversation with engineering, turning "make it consistent" into a specific, prioritizable backlog with a rationale attached to each item, which is what makes it possible to get any of this scheduled against feature deadlines at all.
The bigger shift so far is less about output and more about sequencing: this work moved from something I'd have had to fight for time to do, to something engineering now references when writing Cursor rules and reviewing PRs. That's the leading indicator I'm watching, not a finished system, but a foundation that's starting to get used without me pushing it.
The next phase is getting enough components tokenized that "build from the system" becomes the default instead of the exception.