When Code Is Easier to Read Than Figma: How AI Is Changing What a Product Designer Delivers

When Code Is Easier to Read Than Figma: How AI Is Changing What a Product Designer Delivers

2026-09-15

Partner Story Β· in conversation with Zhengyang Yang. This is a written interview submitted through Submit Your Story. The views below are his own and do not represent any current or former employer. No payment was involved.

Zhengyang Yang, UX designer working on AI-enabled consumer products and design tooling

Zhengyang Yang, UX designer. Photo: courtesy of Zhengyang Yang.

Every software team knows the relay. A product idea starts as a strategy document, becomes a wireframe, then a polished design file, then an engineering specification, and finally something a customer can use. Each handover costs time, and each one loses a little of what the person before meant.

Zhengyang Yang, a UX designer in the Seattle area who works on large-scale consumer products, AI-enabled experiences and design tooling, thinks AI is shortening that relay in a way that changes the economics of building software.

"A surprisingly large amount of product development is lost in translation," he says.

The problem: designers could show, but not demonstrate

Historically, a designer could show what a product should look like. What they could not easily do was demonstrate exactly how it should behave in a real environment: the state changes, the animation timing, what happens on a narrow screen.

That gap is expensive. It gets filled with meetings, clarifying messages, and engineers reconstructing an interaction from a set of screens.

"Software teams are under pressure to move faster without continuously adding people," Yang says. "AI does not necessarily eliminate roles, but it can dramatically expand the surface area that one person can cover."

Three layers where AI does the work

Yang uses AI at three distinct stages of the design process.

The first is exploration. Large language and multimodal models help him work through product scenarios, synthesise information, generate alternative interaction models, and turn an abstract strategy into something visual much earlier than before.

The second is prototyping. Coding agents and AI-assisted development environments let him move past clickable mock-ups and build interfaces that behave like real products. Stakeholders react to an actual interaction instead of imagining one.

The third, and the one that changes how teams work, is implementation. "Increasingly, design and engineering collaboration can happen through code itself," he says. A designer can work inside the project repository, create or modify frontend components, and hand engineers something they can inspect, change or merge directly.

He has also built AI-assisted tooling for other designers. One tool he worked on automates repetitive production work such as filling product interfaces with realistic content, and by his account it has been used by more than 150 designers.

"Some of the most valuable AI applications are not flashy consumer features. They quietly remove dozens of small repetitive steps from everyday work."

The deliverable is changing

Yang is clear that the interesting question is not whether designers should learn to code.

"The more important change is that AI allows designers to operate at a different level of fidelity."

In strategy discussions, a working prototype can make the argument instead of a slide deck. In execution, a designer can talk to engineers through both the design and the implementation. And for small frontend problems, a designer can sometimes make the fix directly rather than filing another ticket that competes for engineering time.

That shifts what a company should expect from the role. "Traditionally, design quality was often judged by the quality of the Figma file," he says. "In an AI-native workflow, the useful output may instead be a functioning prototype, a reusable component, a tested interaction, or even a pull request."

The lesson: code was easier to understand than Figma

The moment that changed his thinking came from engineers themselves.

For years designers have been trained to produce ever more detailed specifications so an intended experience can be reproduced accurately. Once Yang started working with code-assisted workflows, he heard feedback he did not expect: for certain interactions, code was actually easier for an engineer to understand than the design file.

"The goal is not to produce the perfect artifact. The goal is to transfer intent with as little information loss as possible."

When he hands over a working implementation rather than a specification alone, the conversation becomes concrete. Nobody debates what an animation or a responsive state is supposed to mean. They inspect the behaviour directly. Engineering judgement still owns architecture, performance, security, data and maintainability, but a surprising amount of translation work simply goes away.

Where the money is

The economic effect Yang points to is not one large task vanishing. It is the backlog.

Small visual and interaction bugs tend to sit at the bottom of the queue, because engineers reasonably have more critical work. If a designer can diagnose and safely implement some of those fixes, the cost of fixing small quality problems drops, and work that used to wait indefinitely gets done.

"That is where AI becomes economically interesting," he says. "Not because one spectacular task disappears, but because hundreds of small coordination costs start shrinking."

For a business, that means fewer handover cycles per feature, less engineering capacity spent on reconstruction, and a product that ships with fewer small defects, without a proportional increase in headcount.

What comes next

Yang expects the line between design tools and development environments to keep fading. Most teams still keep strategy, design, prototyping, code and review in separate places. He believes the next generation of AI-native product environments will make those stages continuous, so a designer can explore a direction, build a realistic version, test it, adjust the implementation and work with engineering without translating the same idea over and over.

He is especially interested in AI-native product design, design-to-code workflows, agentic interfaces, and tools that make small product teams disproportionately productive.

Zhengyang Yang's work is at yangzhengyang.com.

---

This is a Partner Story: a written interview with someone building with AI, submitted through Submit Your Story and published free of charge. Statements about his work and results are his own. Building something with AI? Tell us about it.

Would you try this product?

0 β€” never10 β€” going to try it right now
Share this article: