Cisco DevNet Designer: HTML Prototypes Replace Figma as the Sole Source of Truth for AI Design Handoff
Alejandro Marrufo, a UX designer at Cisco DevNet, and Casey Tong, Head of UX, documented their experiments during the PubHub redesign: while AI-generated interfaces were functional, they lacked brand identity. The team initially tried converting HTML back to Figma to refine code, but found that interaction details were lost, updates were too slow, and the source of truth became ambiguous. They ultimately shifted to having designers use AI coding tools to refine HTML prototypes directly, accompanied by changelogs and embedded design systems, enabling engineering teams to automatically apply changes to production code.
The PubHub internal publishing tool at Cisco DevNet underwent a time-constrained redesign in 2026. Instead of following the traditional process of designing first and then implementing, the team had an AI coding agent generate end-to-end interfaces directly from user stories and backend APIs. The result was usable: users could complete the main flows, and the interface connected to the backend. However, designer Alejandro Marrufo and Head of UX Casey Tong wrote in a blog post that "usable" does not equal "finished"—the interface did not follow Cisco's visual language, some AI-generated components were unintuitive, and multiple workflows needed cleanup.
This raised a practical question: how can we leverage AI to accelerate design modifications and integrate them into the final product workflow? Their initial attempt involved converting existing HTML pages back into Figma, allowing designers to continue refining in a familiar tool, and then using a Figma MCP connection to sync changes back to code via the coding agent. The idea was appealing—keeping design work within Figma while AI handled the transfer to implementation.
In practice, three issues emerged. First, details were lost in transit: the round trip between Figma and code missed interactions, complete page and button flows, and animations—the very elements that make an experience feel "finished." Second, updates were slower than expected: modifying the HTML prototype via Figma was slower than the project timeline allowed; some pages even had to be rebuilt in Figma and reconnected to flows before any refinement could begin. Third, the source of truth became blurred: with Figma files and HTML prototypes evolving in parallel, it was difficult for designers and other team members to determine which version was current.
Figma is not without merit. It remains a superior tool for maintaining asset libraries and handling fine-grained UI elements. However, under tight deadlines, it is not the fastest place to refine an interface that is already running in code.
So they tried another path: letting AI coding tools inspect the existing prototype and modify its HTML directly. Design work remained within the existing interface, eliminating reconstruction steps. The HTML prototype became the single source of truth. Designers could make staged changes, review each iteration, and provide feedback to the AI along the way. Design work no longer required rebuilding the interface in a design tool first; instead, it targeted a running implementation directly, including interactions and flows that Figma struggled to capture.
A practical constraint quickly surfaced: token limits. Midway through the project, the designer ran out of tokens, switching from Cursor to Claude, then to Codex, resuming once limits reset. The work survived these switches because the HTML artifact—not any specific tool—held the state of the design. They recommend that teams adopting this approach plan for such constraints in advance.
With this approach, designers could edit and deliver working HTML pages daily, producing new iterations. Under the old Figma-first process, a single page took days. This speed created a compounding effect across the team: faster design output meant faster engineering testing, which in turn meant faster feedback for the next design iteration.
The resulting workflow is iterative: the product team defines user stories and backend APIs; an AI coding agent builds an end-to-end interface based on these; designers review the working HTML pages and flows, refining the prototype with AI coding tools; designers hand over the updated HTML artifacts to developers, along with the design system, end-to-end flows for different personas, and a changelog describing the changes; developers pass these to a coding agent, which applies the design changes to the project; the team tests and reviews the results, often live, and repeats the cycle.
The HTML prototype is no longer just a mockup; it has become the handoff document itself. Engineers can use it to accurately reproduce the design, and this approach proved surprisingly popular. Several factors made this possible: an embedded design system (colors, fonts, components, and spacing are placed alongside the page, allowing engineers to reference rules rather than infer them from screenshots); a persona switcher (controls within the prototype allow switching between different user roles, giving engineers clear visibility into each flow and its variants); and a changelog (recording changes per iteration, allowing engineers to apply updates incrementally rather than comparing entire pages).
Regarding syncing design and code, they initially prompted the coding agent with issue lists to fix problems one by one, which was slow and manual. Later, they required designers to include a changelog with each new version. Engineers now hand over both the changelog and the updated HTML to the agent, which automatically applies changes across the project. The handoff shifted from one-off prompts to largely automatic update steps.
Their biggest takeaway was not that more code was written using AI, but that the feedback loop between design and engineering was brought closer together, blurring the lines between the two roles. Reviews became more frequent, with designers sometimes editing in real-time during meetings. Engineers began testing earlier, even performing minor design iterations themselves. The whole team could spend more time on experience and vision, and less on implementation logistics.
For teams wishing to try this method, they listed several practical recommendations: start with a working build, having the AI agent generate an end-to-end interface from user stories and API specs, then design against it rather than starting from a blank canvas; maintain a single source of truth, making the HTML prototype the canonical design and using Figma only where it excels (asset libraries, fine details), avoiding parallel copies of every screen; embed handoff into the prototype, including the design system, changelogs for each iteration, and methods to view all persona or flow variations; explicitly specify what the agent cannot infer, documenting secondary interactions and edge cases so the coding agent doesn't invent them; plan for token limits, expecting to switch AI tools mid-project since the HTML artifact holds the design state, allowing work to continue; shorten review cycles by reviewing more frequently and being open to real-time edits with engineers present; keep the designer's judgment central—AI can quickly produce a functional first draft, but it does not know your design language or which interactions feel right.
For them, this experiment yielded a practical pattern: let AI create the first usable version, let designers refine a functional prototype that also serves as the handoff document, and let the coding agent carry those refinements into the project. This provided a faster path—from an interface that works to one that feels like their own product.