The Distance Between Idea and Evidence: Zhengyang Yang on the End-to-End AI Product Designer

AI has made product design faster in the least interesting sense of the word. Screens appear sooner. Prototypes behave more realistically. Research notes collapse into themes. And increasingly, working code can enter the conversation before a traditional handoff has even happened.

The more consequential change is not speed. It is jurisdiction: how much of the distance between an uncertain product idea and credible evidence can one designer now own?

Zhengyang Yang has been working inside that widening territory. His recent work has included AI-assisted design tooling and functional prototyping, and his framing of the emerging “end-to-end AI product designer” is deliberately less theatrical than the title sounds. This is not the designer-as-superhero who absorbs engineering, research, product management and design. It is a designer who can move farther before the next specialist handoff, arriving with a working prototype, a better-tested hypothesis and more evidence.

That shift is already visible in the tools. Figma describes AI-assisted design as spreading across ideation, research, prototyping, refinement, collaboration and iteration, while its agentic code-to-canvas workflows explicitly move between interface design and implementation. DesignWhine has been circling the same shift through the rise of the AI design engineer, the operating model of an AI-native UX team, and the broader question of what happens when the gates of design fall.

Yang’s answers sharpen all of those conversations around a more useful unit of progress: not how many artifacts one person can produce, but how much uncertainty one person can responsibly remove before the rest of the organisation needs to commit.

The Distance Between Idea and Evidence

The phrase “end-to-end” invites superhero language. Yang resists it. When we asked what this designer actually owns today that a traditional product designer did not, he defined the role by the ground it can cover before another function has to step in.

“I don’t think the “end-to-end AI product designer” is a completely new profession yet. It is an emerging version of the product designer whose ownership extends beyond defining an experience and handing off polished screens.

This person can move from an ambiguous product question to research synthesis, interaction design, a functional prototype, instrumentation thinking and early validation without waiting for every specialist handoff. They are not necessarily the production engineer, researcher or data scientist, but they can now do meaningful parts of those jobs well enough to test an idea before asking the larger team to invest in it.

The biggest change is ownership of the distance between an idea and evidence.

I have experienced this shift firsthand in both product work and internal tooling. Recently, I created an AI-assisted Figma workflow that could populate realistic commerce content into designs. What began as a way to remove repetitive production work became a tool used by more than 150 designers. Building it required more than designing its interface: I had to understand the workflow, structure the content logic, prototype the tool, test it with designers and iterate on its behavior.

I have also found that I can now explore product ideas through functional prototypes rather than relying only on static flows. That changes the conversation with product and engineering. Instead of presenting what a feature might look like, a designer can demonstrate how the system behaves, where it breaks and what assumptions still need validation.

Earlier in my career, creating that level of fidelity would have required more formal coordination among design, engineering and sometimes research. AI has not removed those partners, but it has allowed me to reach a much more informed starting point before involving them.”

The useful distinction here is not collaboration versus independence. Yang is describing a designer who enters collaboration with more of the problem already made tangible. The handoff still exists, but it arrives later and carries less ambiguity with it.

When Design Starts Touching Code

For years, the design-engineering handoff was more than a file transfer. It marked a boundary of accountability: designers expressed intent, engineers made that intent survive contact with a real system. AI is beginning to make that boundary more porous without making it disappear.

We asked Yang how far that collapse has really gone, and whether designers are now expected to prototype, build and validate things that would previously have gone through engineers.

“AI is collapsing the boundary between design and engineering, but in two distinct ways: presentation-oriented prototypes and production-oriented builds. The level of fidelity—and the audience—are different.

At the presentation stage, AI allows designers to create realistic, interactive prototypes much earlier in the process. These prototypes are primarily for aligning with stakeholders, testing the product direction and making a strategy tangible. Instead of explaining an abstract product concept through static screens or a slide deck, designers can demonstrate how it might actually behave. This gives designers a stronger opportunity to participate in product strategy, because they can turn strategic hypotheses into experiences that stakeholders can see, use and respond to.

The build stage happens later, during collaboration with engineering. From my firsthand experience, designers can, on appropriate projects, work directly within a project’s codebase and contribute implementation-level changes under established engineering review. The output can be handed to an engineer as working code, or reviewed and merged through the normal development process.

Engineers I have worked with have sometimes found code more useful than a traditional Figma handoff because it makes the intended behavior, responsiveness and edge cases more explicit. The code is not replacing engineering judgment; it gives engineers a more concrete starting point.

This is particularly effective for smaller front-end issues that do not require server-side changes. In a conventional workflow, these issues can remain unresolved because they are repeatedly deprioritized against larger engineering commitments. A designer who can identify and implement a fix—and then submit it for engineering review—can shorten that feedback loop substantially.

So I do not think the boundary is disappearing completely. What is changing is the designer’s delivery granularity. Designers can move from communicating intent through artifacts to contributing something much closer to the product itself. Engineers still remain essential for architecture, security, performance, maintainability and production accountability, but the space between design intent and implementation is becoming much smaller.”

That is close to the argument behind DesignWhine’s earlier question, do UX designers need to learn coding?, but the AI-era version is more interesting. The point is not that every designer should become an engineer. It is that the artifact sitting between design intent and production may no longer always need to be a Figma file. Sometimes it can be behaviour. Sometimes it can be a prototype. Sometimes it can be code that an engineer reviews rather than interprets.

Smaller Teams, Bigger Expectations

Every productivity story eventually becomes a headcount story. If one designer can research, prototype, generate interfaces, work closer to production and iterate faster, it is reasonable to ask whether companies will simply need fewer designers.

Yang’s answer is uncomfortable precisely because it is conditional. Teams built around artifact production are more exposed. Teams built around judgment may simply find that the amount of design worth doing expands.

“In some companies, it probably will mean smaller teams — especially where design has been treated primarily as a production function. If a role is mostly translating established patterns into screens, generating variations or documenting straightforward interactions, AI can already reduce the amount of human time required.

But increased individual output does not automatically reduce the amount of valuable design work available. It can also raise expectations. When creating and testing an idea becomes cheaper, teams may explore more directions, personalize more experiences and address problems that were previously too small or expensive to prioritize.

The roles under the most pressure are those defined by artifact production rather than decision-making: routine UI assembly, repetitive visual adaptation, basic prototyping and design-system documentation. These skills will still matter, but they will be less defensible as standalone specialisms.

The capabilities becoming more valuable are problem framing, systems thinking, research judgment, product strategy, interaction design for complex or probabilistic systems, and the ability to evaluate quality rather than merely generate output.

AI also makes deep craft more important, not less. When everyone can produce something that looks polished, it becomes harder to distinguish work by surface quality alone. The strongest designers will be the ones who recognize when an apparently polished solution is conceptually weak, behaviorally inconsistent or inappropriate for the user’s context.

I expect fewer roles focused exclusively on producing screens, but greater demand for designers who can connect user behavior, business models, technology and organizational constraints.”

This is where “end-to-end” can become either a description of leverage or a euphemism for understaffing. The same expanded capability that gives a designer more agency can also give an organisation permission to redraw several jobs around one person and call the result efficiency.

Speed Can Masquerade as Understanding

The uncomfortable thing about a functional prototype is that it has persuasive force. It moves, responds and looks more resolved than the thinking underneath it may actually be. Momentum starts to look like evidence.

We asked Yang what worries him most as designers become faster and more technically capable. He went straight to that gap.

“My biggest concern is that speed can be mistaken for understanding.

AI makes it easy to generate plausible solutions before a team has properly defined the problem. A functional prototype creates a strong sense of momentum, even when it is based on weak assumptions. Teams may begin optimizing how quickly they can build rather than asking whether the product deserves to exist.

Research is particularly vulnerable. AI is useful for organizing notes, identifying themes and accelerating synthesis, but it cannot replace direct exposure to users. If designers only interact with AI-generated personas, summaries or simulated feedback, they lose the ambiguity and emotional detail that often reveal the real problem.

There is also a risk of convergence. Models are trained on existing products and patterns, so their first answer is usually familiar, legible and average. If designers accept those answers too quickly, digital products may become increasingly polished but increasingly interchangeable.

Finally, broader ownership can become a disguised overload. A company may describe a designer as “end-to-end” when it really means one person is expected to perform research, product management, design, prototyping, content and front-end development without adequate time or support.

Being multidisciplinary is valuable. Being permanently understaffed is not the same thing.”

The warning rhymes with another thread in our recent coverage. In Brendan Jarvis’s interview on AI and user research, the danger was not that AI could produce nothing useful. It was that polished, plausible output could make it harder to notice when the evidence underneath was weak. Yang sees the product-design version of the same problem: a functioning prototype can create the emotional sensation of progress before the team has earned it.

What Designers Should Learn Next

Yang’s practical advice is almost anti-tool. For all the churn around new AI products, the capabilities he thinks will last are not prompt recipes or software tricks. They are the skills that help a designer move between disciplines without confusing access with expertise.

For an experienced product designer trying to become genuinely end-to-end over the next year, we asked what deserves more investment and what deserves less.

“I would focus on five areas.

First, learn enough front-end development to understand how interfaces actually behave. The goal is not necessarily to become a production engineer, but to work comfortably with components, states, APIs, responsive behavior and data structures.

Second, learn to design AI as a system rather than as a chat interface. That includes uncertainty, latency, user control, failure recovery, evaluation and the relationship between model capability and product experience.

Third, strengthen product judgment. As execution becomes cheaper, deciding what to build becomes more important. Designers should understand metrics, experimentation, business models and how to distinguish a user need from an attractive feature.

Fourth, become better at evaluation. Generating ten options is easy; explaining which one should move forward, what evidence supports it and what could invalidate it is the real skill.

Fifth, improve communication across disciplines. End-to-end ownership does not mean working alone. It means being able to move fluently among design, product, engineering, research and data while knowing when specialist expertise is needed.

I would stop over-investing in pixel-perfect production as the primary proof of design ability, memorizing individual tools and building portfolio case studies that present the design process as a perfectly linear sequence.

Tools will keep changing. The durable advantage is the ability to frame an unclear problem, create the right level of prototype, obtain credible evidence and make a sound product decision.

Ultimately, I see the “end-to-end AI product designer” less as a superhero who replaces a team and more as a designer who can independently reduce uncertainty across a much larger portion of the product-development process. The role becomes dangerous when organizations use it as an excuse to remove collaboration. It becomes powerful when it gives designers more agency over what gets built and why.”

That may be the most useful way to understand the role. The end-to-end designer is not bigger because one person can suddenly do five jobs. The role is bigger because one person can now postpone organisational commitment until more uncertainty has been converted into something visible, testable and discussable.

That is powerful, but it changes the standard. When execution becomes cheaper, judgment becomes easier to expose. When prototypes become faster, bad assumptions can travel farther. And when the distance between idea and evidence gets shorter, the quality of the decision at the end of that distance matters more than ever.