How AI Is Changing the Way Designers and Engineers Build Together

By Victoria Zhang, James Donnelly, Hafsa Ghias, and Nico Aldana

The discourse around AI gains is often focused on how much faster we can get things done. At AKASA, a more interesting change lies in how our teams collaborate and put one of our core values, ‘In This Together,’ into practice. 

Designers with limited coding experience are making changes directly in working prototypes, creating pull requests, and continuing to refine the experience as those prototypes become pilot products. This has fundamentally shifted how design and engineering work together, and, yes, it’s made us faster, too. 

AI making it easier for designers to build working software is already well understood across the industry. For us, harnessing this gain is a bit more complex, given that healthcare is heavily regulated. 

Putting this new ability to use means working through some specific challenges: our products handle complex clinical data, integrate with electronic health records (EHRs), and involve protected health information (PHI). Giving designers the same tools as engineers requires building an environment that supports that work safely, with engineers handling the integrations and production requirements alongside them.

Two recent projects (code-named for confidentiality) provide a closer look. On Project Zipline, one of our designers and an engineer took static mockups into a customer-facing, demo-ready prototype in a fraction of the usual time. On Project Carousel, a designer and an engineer designed, tested, and iterated on a zero-to-one prototype in a single codebase, which became a pilot with a customer. Both were made possible by using AI tooling far beyond just Codex or Claude. 

How It Used To Work

Our previous process will be familiar to many product teams. A designer built a prototype in Figma, iterated based on feedback from subject matter experts, and handed the designs over to engineering to implement the experience.

That process worked, but complex interactions and edge cases were expensive to represent in static screens. Some questions inevitably stayed open until implementation. As the product evolved, Figma and the codebase often drifted apart, leaving the team to figure out which reflected the latest decisions. Designers and engineers spent time translating between those two versions of the product. 

With an AI-native development process (as in the projects mentioned below), designers and engineers collaborate on a single working prototype that serves as both the shared source of truth and the basis for user testing along the way.

Project Zipline: Usable Customer Prototypes

Victoria, the product designer on Zipline, started with static Figma mocks for the initial demos, but quickly saw mockups break when manually propagating changes. Realizing how time-consuming it was to maintain and scale the prototype, she and James, the engineer paired with her on Zipline, connected Figma MCP to Claude Code, and generated a working v1 prototype straight from her mocks in a fraction of the time. 

From there, nearly all the work and demoing moved into the HTML prototype. Victoria used Claude Code to make user experience (UX) changes directly in the shared repository, without an engineering dependency. This enabled her and the team to rapidly test changes with internal subject-matter experts and incorporate insights in real-time during the same feedback session. She still checks her pull requests before merging, but doesn’t have to wait for James to be available to make every adjustment. Now, she relies on engineers mainly when working on complex or data-dependent interactions.

For weeks after her design work was technically complete, Victoria continued fixing small interaction bugs. This eliminated hours of back-and-forth screenshots between Design and Engineering and gave the Design team agency that wasn’t possible before.

Not only did this new way of working accelerate internal processes, but it also unlocked how we engaged with external users. When the team was ready for testing, James helped host Zipline in a staging sandbox so external users could try it. Because the experience now lived in their real workflow tools, customers could experience how the application would fit into their actual work instead of trying to imagine it from slides or a static demo, prompting what the team called “wow moments.”

The sandbox used stubbed demo data, so the team could share it widely while James built the PHI integrations separately. The prototype continued evolving into an early working product headed toward a pilot, without needing a rebuild.

Making the Prototype Useful With Clinical Data

At AKASA, a working prototype must also account for the complexity of clinical data: lab values, vitals, and medical narratives from doctors. Demo data can help develop the interface, but user sessions need enough clinical detail for people to assess whether the product’s outputs are useful. 

On Zipline, Victoria could keep refining the PHI-free version while James moved quickly to build the PHI integrations needed for those sessions.

That also shapes the tools we can use. We can’t use off-the-shelf tools like Replit because they don’t integrate with EHRs, which is what our workflows require. As such, we’ve successfully built our own version of that experience: tools that let designers change, test, and share a working prototype, supported by engineering work to connect it to real clinical data.

Making this practical required some tooling around the code. James shared his skills with Victoria, reducing the friction of onboarding and learning CI/CD processes, including Claude skills for resolving git merges, deploying to sandboxes, and running automated QA in the browser. These tools were a small up-front investment and will enable our entire Product/Design team going forward. The Product team can directly tweak the app to behave the way they need and send PRs to engineers for tasks that would otherwise have gone through a longer process. 

The speed here directly leads to us shipping faster.  

Project Carousel: Code Is the Source of Truth

Hafsa, the designer on Carousel, started the project wary of touching code, for fear of breaking something. Before long, she was using Claude Code to commit changes and was responsible for a large chunk of the front-end work in partnership with her engineering partner, Nico. Her latest design sprint consisted entirely of new features and enhancements going into production. 

Hafsa kicked off a zero-to-one product by designing a few early concepts in Figma and testing them with users. The next step was a clickable prototype to get user feedback. It was an interaction-heavy product, and she estimated that it would have taken two to three times as long in Figma as in code. So she and her engineering partner, Nico, decided to go straight to code. Nico fed the Figma concepts into Figma MCP and produced a working prototype that was roughly 95% of the way to the intended design on the first pass.

From then on, the prototype was where all the design work took place. 

I use Figma to explore different concepts — one to two screens max — and then collaborate with an engineer to flesh out the interaction pattern and the different scenarios in code. We try to prototype quickly to get it into the hands of our SMEs and other users for testing. Based on their feedback, we iterate and refine in code.

Hafsa Ghias, Sr. Product Designer at AKASA

Because users could engage with the prototype directly, they could try interactions that would have been slow and fragile to mock in Figma — like accepting or rejecting AI-generated suggestions and reading full documents inline while searching across content. 

As was the case in Zipline, the team used demo data, so users could inspect full documents and respond to suggestions in a realistic interface. This gave the team useful feedback about the actual product experience.

Granola and Gong, AI note-taking tools, captured sessions with subject-matter experts, and the team fed those notes directly into Claude. That cut down the administrative work of turning conversations into written requirements.

The prototype then became the foundation for a pilot with a roughly one-week deadline. According to Nico, the pilot “would not have been possible to build up from scratch” in that timeframe. Having the prototype in place allowed the team to ship its priority feedback and several nice-to-have requests that would ordinarily have been cut.

For Hafsa, working in code also freed up time for research and repeated sessions with users.

“Code becomes the source of truth now, rather than Figma,” she said. “This new process is also breaking silos between design and engineering.”

What the Teams Gained

Working prototypes made ideas tangible earlier on both projects. Constraints and issues surfaced sooner, so designers and engineers could evaluate alternatives together while there was still time to work through them.

User feedback became more direct, too. People could click through a workflow, inspect documents, and try interactions. The team could apply what they learned to the same prototype that would become the product.

The smaller changes also became easier. 

Moving something a few pixels or adjusting a color used to mean filing a Jira ticket, explaining the change, and checking the implementation. Now, a designer can make the adjustment and submit it for review. With code as the source of truth, there’s less back-and-forth, keeping the design file and application in sync.

AI handled much of the translation work, from turning Figma mocks into a prototype to helping with testing, merging, and deployment. The tools around it, like the AI note-takers, made those capabilities even more practical for the team. 

There’s still more to figure out. James is building a more comprehensive testing tool that lets an agent build and run full UI integration tests in a clean, de-identified environment. It hasn’t been used in design collaboration yet, and the team is curious whether it will help designers test their own changes or remain primarily an engineering tool.

Human Review and Judgment Still Matter

None of this removed the need for human, expert judgment on both projects. AI-generated work still needed review before it went anywhere near production. Victoria and Hafsa remained responsible for user experience and product judgment. James and Nico remained responsible for architecture and production reliability on their respective teams. These responsibilities matter deeply in our workflows. A wrong patient match or a miscoded claim has costs and real-life consequences. 

Fewer Handoffs, More Building Together

Both projects moved faster. And the speed gains came with a useful change in agency, enabling designers to participate in the entire production process. What made it practical for us was the workflow around it.

Getting there required an engineering investment: tools for testing and sharing changes, a PHI-free environment for iteration, and integrations that let the team evaluate the product using clinical data. Adding MCP connections with call notes was also critical for allowing the seamless flow of information between handoffs. 

Ultimately, arming our designers with the ability to code has brought design and engineering closer together and changed the way we work. A small layout or color adjustment can become a code change without another Jira ticket and rounds of screenshots. Code is the source of truth, so there’s less back-and-forth about what needs to change. Designers can keep refining the experience, while engineers have more time for back-end work and integrations. 

That’s made “In This Together” a very practical part of how we now build.

Does this type of collaboration sound interesting? Check out the list of open roles at AKASA on our Careers page.