How KPMG Closed the Design-to-Engineering Gap with Builder
How KPMG closed the design-to-engineering gap with Builder, reaching 88% faster delivery and turning months of idea-to-production into weeks.
For most of his 25-year career designing for digital, Matthew Ardinger, Director of User Experience at KPMG, watched design and engineering run on a familiar rhythm. Designers pushed pixels, handed them to development, and waited. Engineers received those designs and rebuilt them from scratch. The entire path from idea to production took months.
A year ago, KPMG set out to break that cycle by changing how design and engineering worked together, with a new tool as part of that shift.
The gap between intent and execution was the central problem. Designers created non-functional prototypes in Sketch and Figma, then handed them off to engineering. Weeks later, they would review the build, document where it had drifted from the original design, and start another round of redlines. The design and the shipped product lived in two different places, and keeping them aligned had become someone’s full-time job.
The engineering timeline made the problem even harder to ignore. Abhijeet Rokde, Specialist Director of AI & Digital Solutions and a front-end specialist with 15 years of experience, watched designs move from Figma to stakeholder review, then back through another round of updates. Weeks could pass before a single line of production code was written.
When engineering finally received the designs, they had to rebuild the HTML by hand, adding even more time to the process. And because the first build rarely matched the original intent, another cycle of reviews, fixes, and back-and-forth would begin.
KPMG's standards raised the bar further. The firm's reputation rests on how it handles client work, which means security, data protection, and privacy sit at the center of every project. Code passes through layered security scans, and the team scrutinizes every third-party dependency before it reaches a client deliverable. Plenty of AI coding tools could generate something quickly, though only a few could generate something that a consultancy of KPMG's standing could actually put in front of a client.
Watch our recent fireside chat with KPMG on how they reached 88% faster delivery by giving designers and engineers a shared place to build.
KPMG evaluated AI tooling across the market, and two things set Builder apart.
The first was the environment. Most coding tools gave Matthew a prompt and a little room to adjust around it. Builder felt like Figma, familiar enough that making the jump wasn't intimidating, and it let him go into the code once he was comfortable. He found himself manipulating CSS and JavaScript again, work he'd done years earlier and set aside when design tools took over.
The second was Builder's design intelligence system, which Abhijeet came to see as the firm's biggest differentiator. "The problem with most coding tools," as he describes it, "is that they draw on the entire codebase to surface relevant patterns, which makes their output probabilistic. The agent reaches for something and guesses at how the code should be used, and that's where front-end code tends to go wonky."
Builder works differently. It connects to the codebase for the same context, and then it supplies the agent with explicit instructions: what a component is, when to use it, how it works alongside other components in the architecture, how it connects to the back end, all backed by coded examples of when, how, and why to reach for a specific component. Instead of inferring patterns from the code and drawing its own conclusions, the agent follows specific directions on what to use and how to use it.
With that in place, the design team continued to build out a custom component library through a few steps:
- Bringing existing Figma components over into Builder
- Working through a conversation with Builder about how each component should be constructed
- Setting up knowledge and accessibility MD files that feed into every new project
- Building their own scoped packages, since KPMG delivers to clients, and hosting everything in the design intelligence system
New projects now draw on that library, and the team estimates the output comes back close to fully aligned with KPMG branding and approved components from the start. Maintaining the design system used to fall to one dedicated person who owned setup and updates. Now the design team owns it directly, adding and revising components themselves, and the library carries through to every other coding tool they use.
The workflow changed for both sides. Designers push code through pull requests and branches, and engineers move into the design tab. "Designers have become developers," Abhijeet said, "and developers are becoming designers." Where designers once reviewed dev builds, compiled a laundry list of fixes with screenshots, and sent it back, they now make the change themselves, working from the same codebase, so the edit uses the patterns the system already knows. The tight transitions and hover states that used to require sending a reference site and negotiating the result get built directly by the people who designed them.
Human judgment stayed central throughout. Faster prototyping carries its own risk, the kind Matthew calls a "fever dream prototype," where anyone can build something and not all of it is good. The headline here is speed without a quality tax: component patterns indexed in Builder get the team to roughly 80-90% accuracy, with a person validating the rest. Reviews that used to take ten days now happen the same day. The code quality engineers care about because the patterns that enforce it live in the system, and designers pull from the same library.
Behind those numbers, the bigger change is harder to quantify. The story became less about any one person shipping faster and more about shared context, with product, design, and engineering working on the same surface, aware of each other's work, holding joint ownership of what gets built. Design intent survives all the way to production, and over-the-wall handoffs and waiting for word from dev have largely gone away.
The relationship between the teams shifted along with the workflow. Branching was genuinely scary at first for designers used to working solo in a Figma file, where merging into a shared codebase risks overwriting someone else's work. Getting through it took a constant flow of questions met with patience, the kind of partnership that a lot of this depends on.
Now the day-to-day runs as a continuation rather than a string of separate exchanges. When the design library changes, the design team flags it and engineering prompts the system to use the new version. The shared space pulled both roles into a wider view, so the design team now speaks to accessibility and the code, and engineers have more time to improve code beyond the baseline the model produces.
For a firm where keeping product, design, and engineering aligned matters as much as it does at KPMG's scale, that turned out to be the part worth building toward.
