Bring a Working Prototype—and One Question—to Your Product Critique

Which decision should the prototype help you make?

The prototype works. Everyone can click through it. Ten minutes into the critique, the discussion is about button labels because nobody named the decision the prototype was meant to help make.

A working prototype gives a team more behavior to inspect. It also gives the discussion more directions to wander. Bring one question that makes the interaction relevant, then choose the smallest comparison that could help answer it.

What the new capability changes

As checked on 28 October 2026, Figma describes code layers in Figma Design as gradually rolling out in open beta. They put interactive prototypes backed by running code on the canvas. The documentation describes comparing variations side by side and previewing states such as loading, empty and error. Check current availability and access requirements before planning a session around the feature. Figma: Code layers in Figma Design

The practical opportunity is to make a proposed interaction available for inspection. The tool does not decide which question matters or establish how real users will respond.

The review method below works with other prototyping tools too. Figma is the dated capability example, not a requirement for the exercise.

Put the unresolved decision in one sentence

Consider an invented B2B product that needs a workspace name during onboarding. The team is discussing whether to ask for it immediately or defer it until after a user imports a first record.

“Review the new onboarding” is too broad for a useful comparison. A more specific question is:

Should the workspace name be required before the first import, or can someone complete the import and name the workspace afterward?

Now write down what would affect the answer. Does the import require an existing named workspace? Where would a person recognize its destination? What happens if they stop between importing and naming? Engineering and product may already know some answers; others need investigation.

Do that before building two polished journeys. A constraint discovered early can save the team from comparing an option the system cannot currently support.

Hold the comparison steady

Make two small variants:

Use fictional sample records. Keep unrelated design changes out of this comparison. If one version also has better copy, fewer fields and a faster-looking animation, the critique becomes harder to interpret.

List the states the question requires. In this example, the import could be loading, empty or unsuccessful. Someone could return to an unfinished workspace. Choose the states that expose a meaningful difference between the options rather than attempting to prototype the entire product.

Ask colleagues to attempt a task

Give reviewers a task such as “Import the sample record and identify the workspace it belongs to.” Let them follow each variant, then discuss the points where the interaction made a consequence clear or left a question unresolved.

Separate the notes into three kinds:

• Observed in the prototype: a label is absent, a state cannot be reached or a reviewer cannot identify the destination.
• Known constraint: an import operation requires an identifier, supported by the relevant system owner.
• Hypothesis: placing the naming step later may help new users understand why it is needed.

That separation helps the discussion. A teammate's preference is useful feedback, but it does not establish a population-level user outcome. A simulated successful import also does not prove that the real integration behaves the same way.

End with a decision or a narrower uncertainty

A useful critique can end without choosing a variant. It should still leave the team with a more precise next step.

For example:

We have not chosen the step order. Engineering will confirm whether import can proceed before a workspace name exists. Research will investigate whether intended users understand the destination in the deferred-name variant. Both prototypes need a recoverable failed-import state before that comparison.

This is an invented review outcome, not a report of a Figma or CareerJump team experiment.

Keep the decision note with the prototype. Include the question, the compared options, what the review established and the remaining uncertainty. The next person to open the file should be able to understand why those variants exist.

Avoid treating realism as validation

A convincing interaction can make an assumption feel settled. Look closely at what the prototype actually represents: sample data, simulated requests, limited states and any behavior omitted for speed.

Confirm important implementation details through engineering review and investigate user-behavior questions with appropriate research. A working prototype is useful evidence about the interaction it contains; its realism does not automatically extend that evidence to production feasibility or user outcomes.

The professional value of a new tool is often the question it helps you examine. CareerJump's weekly newsletter connects selected developments to your professional context, helping you find a useful angle for the work ahead. See the public examples or build your newsletter.