In a September 24 essay, Figma’s VP of Product argues that a quick prototype does not answer whether the team picked the right direction or made something distinctive. Figma frames strong teams around speed, direction and differentiation. This is a company perspective that also promotes its workflow, not a controlled study of all product teams. The useful challenge is universal: when anyone can make a polished first draft, what evidence justifies turning that draft into a product?
The first result is a hypothesis
A working mockup is seductive because it resolves visual ambiguity. People can click it, so they assume the concept has been tested. But a prototype may show only the chosen happy path and a small set of sample data. It says little about demand, edge cases, permissions, content quality or operational cost. Its value is to make a hypothesis discussable. The next step is not always more visual polish; often it is asking the user to complete a real task.
Teams should write the decision the prototype is meant to support. Is the risk that nobody wants the feature, that users cannot understand it, or that engineering cannot sustain it? Different risks require different evidence. A usability session, a concierge pilot and a technical spike can all be more informative than another generation of screens.
Compare directions before adding detail
Fast tools make it cheaper to explore alternatives, yet teams often use the speed to refine the first plausible idea. Set aside time to make genuinely different directions: a guided flow, a direct manipulation surface, a searchable list, or an automated agent with checkpoints. Ask what each makes easy and what each hides. Comparison gives stakeholders a language for tradeoffs that a single beautiful mockup cannot provide.
Use a common task and consistent evaluation criteria across options. If one design has better sample content or receives more explanation, the comparison is biased. Record where a user hesitates, what they expect to happen and whether the system’s response matches that expectation. Direction should be selected because it solves the observed problem, not because it rendered well.
Differentiation is a product behavior
A brand color and an illustration style may make a screenshot recognizable. Distinctiveness that lasts usually appears in the way a product helps someone decide, recover and finish a job. Consider an AI tool that tells users what evidence supports its answer and lets them correct a mistaken step. That behavior can be more memorable than a decorative animation because it changes whether the user trusts the result.
A team should identify its non-negotiable behavior before creating a pile of variants. What promise could a competitor not copy simply by choosing similar typography? It might be the way uncertainty is handled, the clarity of a handoff or a uniquely focused workflow. Design systems can then preserve that behavior across new screens while leaving room for expressive visual work.
Carry speed through the last mile
Figma’s essay also discusses moving between direct visual edits, prompting and code. The practical insight is to choose the cheapest reliable tool for the kind of change at hand. A spacing adjustment may be faster in a property panel than in a prompt. A data-driven interaction may need code. A repeated review process can become a shared skill or plugin. Forcing every change through one interface introduces friction disguised as consistency.
The last mile includes real data, loading and error states, accessibility, performance and implementation review. A prototype that looks complete before those decisions are made can produce a dangerous feeling of closure. Put the missing states on a visible checklist and test them in a narrow slice of production code. Good handoff exposes uncertainty instead of packaging it away.
The decision gate
Before promoting a prototype, ask for four artifacts: the user problem with evidence, at least one alternative direction, a test result or clearly marked untested assumption, and an implementation plan for the risky states. These are not a bureaucratic stage gate. They are a lightweight defense against the ease of making the wrong thing look finished.
AI can accelerate exploration and production when teams keep judgment explicit. The differentiator is not how quickly a mockup appeared. It is how quickly a team learned enough to choose well, and whether the shipped product still works when the ideal demo conditions disappear. That is the standard against which new design tools should be evaluated.
Questions to take into your next review
- Which user or business assumption does this prototype test?
- What alternative direction was compared fairly?
- Which real-data and failure states remain unproven?