How Plotly Designers Build Beyond Figma Mockups With AI

Written by: Laura Gray, VP People Operations & Dana Dzivinski, People Operations Specialist

One of the most exciting changes we are witnessing after encouraging all team members to embrace AI tooling is how our product designers prototype directly with AI-assisted tools, bringing design ideas to life faster. 

Through AI-assisted coding, sometimes known as ‘vibe coding’, designers are reshaping what collaboration looks like and how they work with engineering in ways that feel both radical and surprisingly natural. 

From mockups to running code

Not long ago, a product designer’s workflow ended at a polished Figma file. They would document their vision, hand it off to engineers, and wait to see it come to life weeks later. Today, we see our product designers generate code directly in the product’s code base, editing the real application. To do this, we lean on repo-integrated assistants like Cursor and Claude Code rather than green-field generators such as Lovable or Claude’s Chat Artifacts.

With AI coding assistants like Cursor and Claude Code, product designers at Plotly are moving straight from concept to production-quality code. AI-assisted coding means a product designer can experiment with UI directly in the same test code repositories as engineers. They can prototype real functionality in a live environment and show exactly how a design feels, in addition to the visuals. The result is faster iteration and better products, built by teams who share ownership from start to finish. When fast exploration is the goal, we’ll also spin up quick off-repo prototypes to test interactions and decide whether they merit a full implementation.

What AI-assisted coding for design looks like in practice

A product designer might begin with an idea in Figma or sketch out an interaction pattern. Instead of creating a spec document and waiting, they open their code editor and prompt an AI model to prototype the experience.

From there, they refine styles, adjust behaviors, and explore different layouts inside the actual product codebase. They preview their work in the running application to understand how it performs in context. When they are satisfied, they open a pull request that includes context and documentation. Engineering reviews every contribution to ensure quality and maintain consistency. At Plotly, product designers are contributing real code rather than just recommendations.

It’s not all in‑app work: teams regularly create lightweight, throwaway prototypes outside the repository to compare options. Building in code is often faster than pushing pixels. It’s interactive, so you can feel the idea by clicking around. Plus, if the idea sticks, the handoff to engineering is usually pretty clean (that is, if the designer doesn’t take it to a PR themselves).

Since they started contributing across our codebases, designers have successfully merged approximately 70% of their PRs, with about 30% closed without merging. And according to Plotly engineering manager Robert Claus, roughly 20% of total PRs in our main application now come from designers.

Why this is a big shift

Most companies talk about improving collaboration between product designers and developers. What’s happening here goes much further.

Plotly product designers are now code-native contributors, working alongside engineers as peers. This unlocks a new level of speed. A product designer can ship a working prototype in hours instead of waiting weeks. It preserves fidelity because there is no loss of detail or nuance between design intent and the final implementation. It creates ownership and accountability since product designers feel responsible for how their work performs and evolves in the real product.

It also inspires creativity. When experimentation happens in live code, the best ideas often emerge through hands-on exploration. By building directly in the product, designers can uncover real-world limitations and edge cases that mockups would never reveal

Where it goes wrong and how we learn from mistakes

Some designer PRs don’t land, and that’s expected. Common reasons include drifting from the design system, performance or accessibility gaps, or long-term maintainability concerns. In general, the changes work best if they only affect the frontend codebase and don’t require any backend changes. A PR review surfaces these issues early and turns them into learnings for the next pass.

Overreach can happen, tugging on cross-cutting architecture or introducing ad-hoc state. Guardrails (linters, CI, preview apps, automated test suites, required reviews) keep experiments from turning into tech debt.

This shift doesn’t turn designers into junior front-end engineers. Their code won’t always be as idiomatic or performant as a specialist’s, and complex features still pair closely with engineering, yet in-product, interactive prototypes dramatically accelerate discovery.

For blue-sky work or big interaction spikes, staying outside the repo is deliberate: faster to iterate, safer for the codebase, and easy to throw away once we’ve learned what we need.

Supporting designers as builders

To help make this shift successful, we have invested in the right foundations. We provide AI training so product designers learn prompting techniques, testing workflows, and the basics of coding in our stack. Mentorship from engineering partners helps product designers build confidence and grow their technical skills.

We create safe spaces for experimentation with dedicated feature branches and preview environments that let product designers try ideas without risk to production. We maintain clear standards so every contribution goes through the same review process as any other code, ensuring quality and consistency. Most importantly, we trust our teams to experiment, learn, and iterate. Everyone understands that not every idea will ship, and that’s part of what makes this approach valuable.

Looking ahead

The future of product development will belong to hybrid builders, people who can design, prototype, and ship experiences from start to finish. At Plotly, we are already living that future. Product designers are rewriting the rules by writing the code. And we are just getting started.