How We Took a Product Design Cycle from Four Weeks to Just Over One

In brief: Going four times faster started with understanding what the client actually needed: speed they could trust, with designs that were validated and ready to build. So we focused the team on building the rails first. We ran requirements, design, and design-system work side by side. We matured the design system until AI could handle most of the production work by sprint three. And we validated drafts in live code with business, development, and data in the same room. The team grew from three to six along the way, but it was the rails, more than the headcount, that made the speed possible.

Part one of this series argued that AI has moved the design bottleneck from making to knowing. Part two looks at the making side of that story: what we changed, sprint by sprint, inside a large life sciences program to take our design cycle from four weeks to just over one.

Four weeks per design cycle. That was where we started with a large healthcare and life sciences enterprise, and the client needed it to be far shorter. Asking our designers to work harder in less time was never going to close that gap. So we rebuilt how the work flowed, one sprint at a time. Here is how it unfolded.

We started with a slow, traditional design workflow on purpose

Our design work began in a traditional workflow that was small and static, focused on discovery and on building our design system and UIs. It was careful, capable, pixel-by-pixel work, and it was slow by necessity. We knew almost immediately that this way of working wouldn’t scale to what the program required. That early friction told us what needed to change.

We built the rails before we tried to go fast

Our client’s scope kept growing while the timeline stayed fixed, which meant we needed to move roughly four times faster. Just as important, they needed speed they could trust: designs that were validated and ready to build. Once we understood those expectations, we aligned the team around building the rails that would let us move fast without giving up either. Two things worked together on those rails: systems thinking that reorganized the work, and close collaboration with AI that changed how we did it.

The first rail was parallel work. Our old model was sequential. We elaborated a requirement, then designed it, then extended the design system to support it, with each step waiting on the one before. With the team spread across multiple time zones, we ran those steps as concurrent workstreams. Business-requirement elaboration, design execution, and design-system scale happened at the same time instead of in a line. Much of the speed came from removing the waiting.

The second rail was the design system itself. We dedicated specialists to building and scaling it, including tokenization, scalable patterns, and documentation, rather than producing screens. Moving design time away from drawing UI can look like a loss on a delivery timeline. In practice, it is what allowed the rest of our team, and AI, to produce designs at speed later.

Our design team did grow, from three to six by the second sprint. Anyone who runs the numbers will spot the gap: twice the people shouldn’t produce four times the speed. Extra hands let a team carry more work at once, but they don’t shorten the time each piece takes. The added capacity went into the rails, and some of our new hires were there to make the size of the team less important. Those rails are what let every designer, and every AI agent, spend their time on thinking instead of production.

By sprint three, our design system was ready for AI-led design

By sprint three, our design system had matured enough that we could design almost entirely with AI. This was the turning point. Our designers could spend nearly all their time collaborating with subject-matter experts, business analysts, and development partners to work out real solutions inside the designs, and to do it faster.

This speed came from a system that let designers think, strategize, and design faster, and not from designers working harder with their hands. When producing a screen becomes nearly free, a designer’s time goes to the part that creates value: understanding the problem and shaping the right solution with the people who know the domain.

We designed in live code, inside a fixed validation process

In a highly regulated program like this, the validation process is not negotiable, and it shouldn’t be. QA, UAT, and SME sign-off all had to clear before anything shipped, and our deploy dates were fixed around them. We planned backward from those dates. Our design timeline had to be aggressive so that finished, working design and development could reach those validation stages with enough runway for SMEs to catch and fix issues before the final product deployed. AI sped up how quickly we reached those gates, not how quickly we moved through them. Nothing an AI agent produced went anywhere untouched. All of it moved through the same version-controlled pipeline and the same human review and validation as any other work.

This also shaped what our designers could build. Because we designed directly in the React application, using the same JavaScript frameworks as our development team, the micro-interactions we designed were realized in real time. We could design in the spaces that static prototyping used to leave blank. Tools like Figma Make got us part of the way by generating on-brand screens from our components. But a prototype can only show the main moments of an experience, meaning the states and the screens. The transitions and micro-interactions between them are left to the imagination until development builds them. Working in live code, we could design that connective tissue directly and shape the entire experience instead of a series of snapshots.

The bigger advantage was having the code itself outside of Figma, more than any single tool or platform. That let us work with a range of agents and tools to fine-tune the output to fit users’ needs.

Faster design made data gaps easier to miss

This speed came with a real risk. The faster and more convincingly we could design, the further we could get down a path before discovering that the data underneath couldn’t support it. In one capability, we were designing part of a system for measuring a clinical trial’s health. We designed a visualization that assumed we could show a daily health score over time. It looked right, and it demoed well. Weeks later, during data mapping validation, we learned that the underlying product wasn’t calculating or retaining those scores historically. The design implied a history the data had never captured, and the work had to be unwound.

This wasn’t an isolated case, and the causes varied. Sometimes the data we wanted to show wasn’t captured by any source system, occasionally because capturing it would have taken more time and effort than the project timeline allowed. Other times, the data existed but couldn’t be presented the way our design assumed. For example, aggregating the data could double-count records because of how it was stored, or roll it up into a metric that looked precise but was quietly misleading.

The common thread was that a design could be entirely reasonable on its face and still commit to something the data couldn’t deliver. Most often, this happened where business requirements described an ideal end state before the data and technical assessment had caught up.

Drafting and validating together cut the cycle to just over a week

Our designers created early drafts fast, then moved into blueprinting to validate those designs live, with business, development, and data in the room when available. We drafted quickly, then pressure-tested the designs against reality together.

As a result, our design timeline dropped from four weeks to just over one. The gain came from closing the distance between drafting and validating, so a wrong assumption got caught in the same conversation that created it rather than weeks later. We stopped reviewing designs in disconnected pieces and asking stakeholders to imagine how it would all come together. We gave them a complete, working prototype early. They could experience the whole thing at once, and we could workshop it together without anyone having to picture the final product from fragments.

Acceleration in AI product design means removing work that never needed a human

Done well, acceleration is less about pace and more about removing the work that never needed a human, so people can spend their time on the work only they can do. We didn’t make designers faster. We made the design system, the tooling, and the rhythm carry the weight that used to fall on the designer’s hands.

All of it rested on one foundation: a design system engineered so that both humans and machines could build from it safely. That foundation is the subject of the next article.

Next in the series: the design system we built for humans and machines.