Context
At LendWell, we are building an AI-powered mortgage and financial services platform across both adviser and applicant experiences. As our engineering team began adopting AI-assisted development tools such as Claude Code and rapid prototyping environments, our traditional design process—heavily centred around Figma, sequential workflows, and handoff—started to break down.
Instead of trying to preserve that model, we redefined how design operates across the company.
The Problem
The traditional design process has been treated as gospel for years, but that model is breaking down.
Designers were trained to spend the majority of their time producing artifacts—wireframes, mocks, polished prototypes—but that way of working is no longer viable. As engineering velocity accelerates, especially with AI, the value of static deliverables is collapsing.
Designers simply don’t have the time to craft perfect screens anymore, nor is that where the highest leverage lies. Increasingly, the role is shifting toward helping teams execute, shaping direction in real time rather than handing off finished work.
At the same time, the role of the product designer as we’ve understood it over the last decade is effectively dead. Not because design is less important, but because everyone is now a designer. Engineers are generating UI directly. PMs are prompting flows. AI tools are producing variations instantly. The scarcity is no longer in making things—it’s in deciding what’s worth making, what’s good, and what should never ship.
This fundamentally changes the job. Designers are no longer the sole creators of interfaces; they are becoming curators of outputs and the final line of quality control. Taste, judgment, and coherence across a product are now the differentiators, not the ability to push pixels.
How this shift presented at LendWell
This led to fragmentation across the product. Multiple versions of the same interface existed across Figma, prototypes, and production. Design patterns were applied inconsistently, and designers risked becoming bottlenecks rather than enablers. It became clear that the issue wasn’t execution—it was the underlying operating model.
The Problem Existed Before AI…
IDEO unintentionally unleashed a monster that consumed real design by turning designers into professional facilitators for most of the past decade.
Throughout the 2010s, design was widely adopted but poorly implemented. Design thinking was scaled across organisations, but in many cases it became a proxy for consensus-building rather than decision-making. The result was design by committee: slow, diluted, and often disconnected from actual product quality. Designers were positioned as facilitators of process instead of owners of outcomes. This created a false sense of rigor while often producing mediocre results.
What’s happening now is an opportunity to reset. As the cost of creation trends toward zero, the cost of bad decisions compounds faster than ever. Shipping is easy; shipping the right thing is not. The teams that win will not be the ones with the most designers producing the most artifacts, but the ones with the strongest point of view—where designers act as editors, curators, and arbiters of quality across an increasingly autonomous system of builders.
This led to fragmentation across the product. Multiple versions of the same interface existed across Figma, prototypes, and production. Design patterns were applied inconsistently, and designers risked becoming bottlenecks rather than enablers. It became clear that the issue wasn’t execution—it was the underlying operating model.
Our Approach
In response, we redefined our approach around a single principle: the design system must live where products are built—inside code. This led us to adopt a four-layer model that separates exploration, experimentation, implementation, and governance.
Figma was repositioned as an exploration tool. It is now used primarily for divergent thinking, early-stage flows, and refining visual and interaction ideas. Rather than treating it as a source of truth or a place to maintain exhaustive component libraries, we use it to define intent. This shift allowed us to focus more on solving problems than maintaining artefacts.
Alongside this, we introduced a lightweight prototyping layer using tools like Lovable and code-based environments. These are used selectively to validate flows in more realistic contexts, particularly for AI-driven interactions where behaviour is difficult to fully model in static designs. Importantly, this layer is optional. In many cases, we move directly from exploration to implementation without formal prototyping.
Implementation
The core of the system now lives in code, authored and maintained using Claude Code. This includes design tokens such as colour, typography, spacing, and motion, as well as component primitives, variants, and composition rules.
Accessibility and interaction standards are embedded directly into these components. By moving the system into code, we ensure that it is enforceable and usable by both engineers and AI tools. If a component does not exist in code, it is not considered part of the system.
Storybook serves as the operational home of the system. It functions as a living contract between design and engineering, providing canonical component definitions, usage guidance, and real implementation examples. It replaces Figma libraries and static documentation as the primary reference point for building UI, and acts as a shared surface for alignment, onboarding, and quality assurance.
A New Workflow
Getting Past the Discomfort
This transformation didn’t just change our tools or workflows—it fundamentally challenged what it meant to be a designer at LendWell. Rather than resisting the shift, we made a conscious decision early on to accept it. Our internal mantra became simple: it is what it is. AI was not a passing trend or something we could optimise around at the edges—it was a structural change to how products are built.
In practice, this meant becoming more resilient and pragmatic as a team. We had to let go of control in some areas while becoming significantly more opinionated in others. Rather than defining every screen, we began defining systems, constraints, and principles that could guide output at scale. We shifted from being primary creators of UI to stewards of quality and coherence across rapidly evolving interfaces.
By leaning into the change rather than fighting it, we were able to reposition design as a force that scales with engineering and AI, rather than being constrained by them.
Impact
The impact has been significant. Teams are able to move faster without sacrificing consistency or quality. Design is no longer a bottleneck, but a force that shapes and refines output as it is built. Because the system exists in code, it is naturally adopted by engineers and AI tools, leading to stronger alignment across the organisation.
One of the key lessons from this shift is that Figma still plays an important role, but it is no longer the centre of the design process. Its strength lies in exploration, not enforcement. We also learned that design systems must be machine-readable to function effectively in an AI-enabled environment. Documentation alone is not enough; the system must actively constrain and guide what gets built.
As we continue to evolve, we are exploring AI-aware design systems that can be directly consumed by generation tools, deeper integration between Storybook and AI workflows, and automated quality assurance driven by system rules.
Ultimately, this transition is not just about tools. It represents a broader shift in how design operates within modern product teams. By moving our system into code and redefining the role of design, we have built a model that scales with engineering and aligns with how products are actually built today.