Your AI prototype looks finished. Is it ready for real people?

Name what the prototype proves

A prototype may help communicate a concept, compare navigation, or test whether someone understands an interaction. It does not automatically prove that authentication, storage, payments, permissions, or integrations work. Write down which parts are functional, simulated, and absent. Show this distinction to stakeholders so a successful demonstration does not become an accidental production promise.

Trace one complete task

Choose a specific person, starting condition, and desired result. Follow the task from entry to confirmation. If the screen says “saved,” reload and check whether anything persisted. If the interface claims to send an email, verify that the delivery path exists. In a purely visual prototype, label such actions as simulated. Do not invite real customers to depend on behavior the prototype cannot provide.

Inspect the overlooked states

List loading, empty, partial, error, success, permission-denied, and interrupted states. Try long names, missing images, invalid input, and small screens. What happens if an external service fails? Can someone retry without submitting twice? These questions create a useful implementation brief even before the team chooses a technical solution. They also reveal whether the core concept still makes sense outside the ideal demo.

Use AI for alternatives and review prompts

Ask for three ways to communicate an error, or a list of questions about a flow. Supply the task, constraints, and approved product facts. Treat suggestions as proposals to inspect. A useful prompt is: “Review this flow for missing states. Separate observable issues, assumptions, and questions. Do not claim you tested behavior you cannot execute. Suggest a verification step for each concern.” Keep confidential inputs within your organization’s approved tools and processes.

Evaluate usability and accessibility deliberately

Observe relevant people attempting a realistic task. Avoid coaching them through every step, and record where they hesitate or recover. Review keyboard operation, focus, labels, text contrast, and the meaning of status messages. Use authoritative accessibility guidance and appropriate testing. An attractive generated interface or automated checker result is not an accessibility certification.

Create the implementation handoff

For each screen, record the user action, data read or written, validation rule, permission requirement, state transitions, and completion behavior. Add acceptance criteria for the most consequential paths. Example: after a valid submission, a confirmation identifies the saved record; after a failed save, the entry remains available and the user can retry. Engineers should help define technical and operational constraints before the team commits to a launch date.

Choose the next useful investment

If you are still unsure whether the task solves a meaningful problem, test the concept. If the concept is clear but the flow is confusing, review the design. If the flow works and the missing work is infrastructure, scope engineering. UXDesignCoach’s review helps prioritize one journey; the prototype sprint starts at $2,500 for up to five screens, a clickable prototype, one revision, and handoff. Production development is separate.

Further reading

W3C WAI: forms, labels, instructions, and feedback. Use this guidance alongside implementation testing; this article is not a conformance audit.

Keep exploring

A better-looking redesign is a hypothesis. Here is how to test it.

How to prioritize UX friction without giving your product a made-up score