A convincing prototype can hide an unresolved question
AI tools can turn a short description into a screen that looks ready for a presentation. The layout is coherent, the buttons have labels, and a plausible journey appears within minutes. That speed can be useful, but it also changes the risk. A team may begin evaluating the polish of an answer before agreeing on the problem. The prototype becomes a persuasive object, while assumptions about the user, task, information, and failure states remain invisible. Good design work makes those assumptions inspectable before the artifact acquires authority.
Figma's 2026 AI report discusses how AI is changing collaboration and design workflows. It provides context for the current attention around generated interfaces, but a vendor report does not establish that every team becomes faster or produces better outcomes. This guide offers an original review process for a hypothetical appointment-booking prototype. It does not claim a completed client study or measured productivity gain. Read Figma's 2026 report.
Start with a decision the prototype can inform
Write a question that can be answered through observation. Can a first-time visitor understand which appointment type they need? Can someone change a booking without losing the relevant information? These are narrower and more useful than asking whether the app looks modern. The prototype should expose the interaction required to answer the question. If the question concerns understanding a cancellation policy, a beautiful dashboard may contribute little. Match the fidelity and scope to the uncertainty rather than generating an entire product because the tool can.
Record what the prototype deliberately does not represent. It may use fictional availability, simulated account states, or a fixed result after submission. Tell the team which behaviors are mocked. A prototype that appears to calculate real prices can mislead reviewers if the output is actually a hardcoded example. The distinction matters during research as well as internal approval. Participants should not be encouraged to provide real sensitive information to a simulation that was created only to examine a navigation or comprehension question.
Give the generator a bounded brief
Specify the user context, task, content requirements, and constraints. Include a small set of realistic records and the states you need to inspect. A request to make the experience delightful leaves too much room for the tool to choose the actual product behavior. A stronger brief explains what happens when no appointments are available, which information must remain visible, and what the user can change. The generator can then accelerate exploration inside a defined problem rather than inventing a convincing business process.
Keep the first prompt and the resulting assumptions with the prototype. If the tool adds a membership requirement, recommendation panel, or payment step, decide whether that behavior belongs in the research question. Do not accept it merely because it makes the screen feel complete. Generated defaults can quietly become product requirements when nobody records their origin. A short assumption log gives the team permission to remove plausible but unsupported features before they become part of a roadmap or a polished case-study narrative.
Audit the content before the layout
Read every label, explanation, price, date, and status. Generated copy can sound credible while contradicting the service. A booking prototype might promise instant confirmation even though the real process requires staff review. That is a product decision, not a harmless wording choice. Replace invented facts with approved content or clearly marked fictional data. The quality of a research session depends on the participant responding to a scenario that represents the question you intended to investigate.
Check whether the content remains coherent across screens. The same appointment should not change duration or location after a user edits a field. A back button should preserve the state the prototype claims to support. If the simulation cannot do that, narrow the task or explain the limitation to the research team. A disconnected sequence can make participants appear confused for reasons unrelated to the design hypothesis. Content continuity is part of prototype fidelity, even when visual detail remains intentionally rough.
Inspect the missing states
List empty, loading, error, unavailable, success, and interrupted states for the chosen task. A generator often produces the ordinary path more readily than the awkward one. For the booking example, ask what happens when the selected slot disappears, the network fails, or the person needs to change a detail after reviewing the summary. You do not need to implement every production condition. You do need to decide which conditions could affect the research conclusion and represent those with enough accuracy to observe them.
Write a recovery path for each included failure. A message saying something went wrong is not a complete interaction if the participant cannot tell whether a booking exists. The prototype should show what information is retained and which action is available next. These details often reveal more about the design than another round of visual refinement. A useful review asks whether the user can form a correct understanding of the system, not simply whether the error message is styled consistently with the rest of the interface.
Check the interaction with a keyboard
Move through the task without a pointer. Confirm that controls can be reached, focus is visible, and the order follows the content. Open and close overlays, inspect validation, and return to the triggering control. Generated markup can look correct while using elements that do not behave like the controls they resemble. This check does not establish full accessibility, but it can identify obvious barriers before a participant encounters them. A prototype used for research should not silently exclude people whose interaction differs from the generator's default assumption.
Avoid treating accessibility findings as unrelated technical cleanup. If a participant cannot reach the primary action, the design question has already changed. Record the barrier and repair the relevant interaction before interpreting task performance. Where a limitation cannot be fixed within the prototype, state it in the study plan and consider another format. The research should distinguish a problem in the proposed service from a problem introduced by the temporary artifact used to represent it.
Plan tasks that do not reveal the intended route
Describe a goal in the participant's terms instead of naming the button you want them to choose. Ask them to move an appointment to a suitable day, rather than telling them to use the reschedule control. Let them explain what they expect before an irreversible action. Neutral tasks reveal interpretation, while leading instructions can make an unclear interface appear successful. The moderator should know where the simulation is limited without coaching the participant through the design's weak points.
GOV.UK's service manual describes moderated usability testing as a way to observe people attempting tasks and understand problems. Its guidance is a research reference, not a claim that one session validates an entire product. Use it to plan recruitment, tasks, consent, and observation appropriate to the study. Review moderated usability testing guidance. A generated prototype is a research instrument whose usefulness depends on how the study is designed.
Separate observation from interpretation
Record what the participant did, what they said, and the relevant system state before writing the explanation. A participant pausing on a summary page is an observation. Concluding that they distrust the brand is an interpretation that needs support. Keep the two separate so another reviewer can assess the reasoning. A polished AI-generated screen can encourage an equally polished story about its effectiveness, but the evidence still needs the ordinary discipline of careful notes and a traceable link to the research question.
Use a small issue log with task, observation, severity rationale, affected state, and next investigation. Do not turn a handful of sessions into a universal percentage about all users. Counts can describe the sample, but the sampling method and context limit the conclusion. A useful result may be that several participants misunderstood a label and the team should test clearer wording. That is enough to justify a bounded revision without claiming that the change will increase conversion by an invented amount.
Evaluate the speed of learning, not just generation
Track time spent on briefing, generation, correction, research setup, observation, and revision. A tool that produces a first draft quickly can still require substantial repair before the artifact is useful. Compare the whole workflow with an appropriate alternative rather than timing only the most impressive stage. The relevant output is a better-supported design decision. A prototype that takes slightly longer to prepare but answers the right question may save more work than one that reaches a presentation quickly and leaves uncertainty untouched.
Keep a record of discarded directions and why they were discarded. This prevents later reviewers from mistaking the final artifact for the first obvious answer. It also helps distinguish useful AI exploration from decorative variation. Ten versions that change only color do not provide ten independent ways to solve the interaction problem. Exploration earns its place when it makes the tradeoffs clearer, reveals an assumption, or gives research a meaningful comparison to investigate.
Hand off the evidence with the artifact
When a direction moves toward implementation, package the scenario, assumptions, tested states, findings, unresolved questions, and content sources alongside the screens. Mark generated code or behavior that has not been reviewed for production. A developer should not need to infer security, data handling, or business rules from a prototype built to explore one interaction. The handoff should explain which parts are design intent and which are temporary simulation. That boundary protects the research from being overextended into a specification it was never meant to provide.
AI prototyping is most useful when it lowers the cost of examining an idea without lowering the standard of evidence. Define the question, audit the content, inspect failure and recovery, and observe realistic tasks. Then judge whether the process helped the team learn something consequential. The impressive first screen is a starting point. The valuable result is a decision whose reasoning remains clear after the excitement of rapid generation has passed.
