How to Build and Test a Gemini Canvas Prototype

How to Build a Prototype in Gemini Canvas

Gemini Canvas can help turn a bounded idea into a clickable prototype. Use it to explore one user job, interface, and behavior with synthetic data. Do not treat the preview as a production website or application. Review the generated code, test the artifact, export or copy it into a proper development workflow, and assign a qualified owner before real data, credentials, payments, authentication, or external writes are introduced.

The example below is a local coverage-comparison card. It uses fictional marine-insurance options and performs no policy interpretation, quote, transaction, or data collection.

1. Define one user and one job

Start with a sentence that can be tested.

"A small-business owner can compare three fictional coverage categories and see which questions to take to a licensed professional" is bounded. "Build an insurance platform" is not.

The prototype should not recommend coverage, calculate a premium, collect contact information, bind a policy, store a selection, or call an external service. Those non-goals prevent visual polish from quietly expanding the system.

flowchart LR
    A["One user job"] --> B["Non-goals and safe data"]
    B --> C["States and acceptance tests"]
    C --> D["Small Canvas artifact"]
    D --> E["Code and preview review"]
    E --> F["Export with known issues"]
    F --> G["Production engineering and release"]

2. Write the states before the prompt

The interface needs more than a happy path. Define the empty state, initial state, valid selection, invalid input, unavailable information, and reset behavior.

For this example, the initial state shows three fictional categories and plain-language questions. Selecting a category reveals a short, explicitly illustrative description. Reset returns the interface to its initial state. No answer claims that coverage exists or applies.

Turn those states into acceptance tests.

The test language should be observable. "Looks good" is not an acceptance criterion.

3. Use synthetic data and prohibit side effects

Create obviously fictional names, prices, people, organizations, policy forms, and claims. Do not paste a customer's submission, quote, claim file, email, address, account number, policy, medical detail, credential, API key, proprietary source code, or licensed asset into the public exercise.

The Gemini Apps Privacy Hub explains how account settings affect activity storage, model improvement, human review, and temporary-chat retention. Those controls matter, but they do not replace authority or data minimization.

For the first prototype, prohibit authentication, payments, file uploads, databases, analytics, location, email, external APIs, and any operation that writes outside the preview. Every added integration creates a trust boundary that the prototype is not designed to own.

4. Ask for the smallest artifact

The current Canvas help page documents app creation, direct code editing, console output, recent changes, and selected-area prompting. Use those features to keep the artifact inspectable.

A prompt brief can be written as short prose:

Create a single-page educational prototype for comparing three fictional
marine-insurance coverage categories. Use only local synthetic data. Do not
collect, store, send, or infer personal information. Do not use external APIs,
authentication, payments, analytics, file uploads, or network requests.

Show the purpose and fictional-data notice first. Provide three named controls,
a detail region, a reset action, visible focus, semantic HTML, useful error
messages, and responsive layout. Make every function available by keyboard.

Return the smallest implementation that satisfies the attached acceptance
tests. Explain the file structure, dependencies, and known limits.

Attach the acceptance tests rather than asking the model to invent its own definition of done.

5. Inspect the code before admiring the preview

Open the code view. Identify the framework, files, dependencies, state model, event handlers, storage, network calls, generated content, and data flow.

Search for hardcoded secrets, hidden trackers, remote resources, unsafe HTML injection, dynamic code execution, unexpected persistence, broad permissions, and unhandled input. Confirm that the implementation actually uses the synthetic data you approved.

The OWASP Secure Code Review Cheat Sheet explains why manual review still matters alongside automated testing. It calls out application boundaries, dependencies, input validation, authentication and authorization, secrets, configuration, error handling, logging, and business logic. A beginner should not interpret the checklist as proof that they can approve unfamiliar production code. It describes areas a qualified reviewer must own.

If you cannot explain what the code does, the next action is review, not deployment.

6. Test the preview as a user

Run every acceptance test. Use the interface without a mouse. Zoom the page. Narrow the viewport. Enter unexpected values if the interface has input. Trigger empty and error states. Inspect the console. Reload and confirm what persists.

The Web Content Accessibility Guidelines 2.2 are the W3C Recommendation for web-content accessibility. A small prototype should at least expose semantic controls, programmatic names, keyboard operation, visible focus, useful instructions and errors, readable contrast, and a meaningful order. Automated tools can help, but they do not replace keyboard, screen-reader, zoom, and human review.

Record every failed test. Do not prompt "fix accessibility" and accept the next visual result. Name the behavior that failed, ask for a focused change, and rerun the full relevant set.

7. Test changes for collateral damage

An AI-assisted edit can fix one symptom and change something you did not ask to change.

After every meaningful revision, inspect recent changes or compare the exported source. Rerun the original tests, not only the test that failed. Confirm that labels, fictional-data notice, keyboard behavior, error handling, and no-network boundary remain intact.

If the Canvas version controls behave unexpectedly, stop editing and preserve the current source outside the conversation. Venture Step E061 recorded a version-navigation problem in the 2025 launch surface. The current product documents saved versions and recent changes, but only a dated account test can establish current behavior.

8. Review the share boundary

Google's current help page says a shareable public app link can let anyone with the link view and edit data associated with the app. It also describes optional Gemini-powered features, cross-user data, and data saved across sessions and devices.

Do not assume that a shared Canvas link is a private staging environment. Review the current app information, use only synthetic data, open the link in a separate test context, and record what an unauthenticated or different user can see and change.

For this workflow, sharing is optional. A source handoff is safer than a public preview when the team has not reviewed the exact link behavior.

9. Export a review package

The handoff should contain the exported or copied source, a dated prompt, the acceptance tests, synthetic data, dependency list, screenshots or recordings of failures when rights permit, known issues, and the current source URL for Canvas behavior.

It should also state what was not tested. Examples include screen readers, browser combinations, load, mobile devices, security scanning, dependency vulnerabilities, data protection, or production hosting.

PROTOTYPE HANDOFF

User job

Non-goals

Data classification and synthetic-data source

Canvas date, account type, device, and visible mode

Prompt and acceptance tests

Source files and dependencies

Passed and failed tests

Known issues and untested areas

Production requirements

Named receiving owner and review date

The receiving owner should be able to reject the artifact or require a rebuild.

10. Rebuild the production boundary deliberately

Move the source into a repository with the team's normal review and release controls. Reevaluate the architecture before adding real data or external behavior. A prototype optimized for speed and demonstration may not be the right foundation for production.

Define data ownership, authentication, authorization, input validation, server-side enforcement, secrets, dependency policy, privacy, accessibility, observability, backup, rollback, incident response, and support for the actual system. Test the final deployed surface, not only the local or Canvas preview.

[[How to Review AI-Generated Assets Before Publishing]] provides the common release gate across text, images, and interactive work. [[What Gemini Canvas Is]] maintains the current product boundary.

Editorial note

This is a prototyping workflow, not production architecture, security certification, legal advice, insurance guidance, or accessibility conformance determination. Current Canvas behavior was checked through official documentation on July 28, 2026, not an authenticated account test. The draft was developed with AI assistance from the preserved episode and cited sources, then prepared for product, engineering, security, privacy, accessibility, insurance, and human editorial review. Publication and deployment have not been authorized.