A volunteer group needs a mobile wayfinding screen for a community garden. The real site has a main gate marked B, a paved approach, and a short segment whose step-free status has not yet been inspected. An AI-generated interface can produce convincing green arrows and wheelchair icons, but a polished route is not evidence that the surface is actually accessible. The most important work happens before any design is shared.
Google Stitch is an AI-assisted design canvas that can generate, reflow, and refine interface concepts from descriptions and other context. Google introduced a live design agent in 2026 and describes ways to move the resulting interface into other development tools. This fictional example uses Stitch to explore layout and language while keeping gate and route decisions with a human site owner. It is not a live software test or a map of an actual garden.
Build a route evidence sheet before the prompt
Make a one-page source sheet with the gate identifiers, confirmed path segments, physical barriers, and the person responsible for field verification. In this teaching example Gate B is confirmed, the main approach is paved, and a connector near the planting beds has unknown step-free status. Do not erase the uncertainty by assigning a reassuring icon. The source sheet should distinguish observations from plans and specify when each fact was last checked.
Take photographs or measurements only when the project has permission, and keep any visitor information out of design prompts. Record the wording that may be displayed: “Gate B,” “Paved path,” and “Route segment awaiting inspection.” An accessible map should not convert an unverified connector into a wheelchair route. Even a route that appears smooth in an illustration can include a slope, gate width, or obstruction that makes it unsuitable.
Use Stitch to explore a screen, not to certify a route
In the Stitch design canvas, describe the intended mobile screen, the verified labels, and the visual hierarchy: a prominent gate identifier, a simple path drawing, a legend, and a conspicuous note about the unknown section. Ask the design agent to keep the path uncertainty visible and to use neutral rather than affirmative accessibility language where evidence is missing. Use the generated layout as a wireframe, not as a survey result.
Google describes starting designs with natural language, voice, files, and context, plus a canvas for rapid iteration. Availability and export routes depend on the current product experience. Instead of assuming a particular unpublished menu or account capability, follow the official Stitch guidance shown in your workspace. Do not upload real visitor lists, protected site plans, or third-party photographs without authorization.
Compare variants without allowing fictional geography
Ask for two layout options: one with a horizontal path card and another with a simplified map-and-details panel. The content in both must stay identical. Compare type size, the visual distinction between confirmed and unconfirmed routes, and whether Gate B remains easy to find. A variant that adds a second gate, a ramp symbol, or a convenient shortcut should fail content review even if its spacing is attractive.
A useful prompt revision is explicit: “Keep the unknown connector dashed and labeled pending inspection; do not show it as a step-free route.” Check every path segment visually after regeneration. An agent may optimize the design by smoothing corners or adding decorative paths. Treat those as design proposals only. If the agent cannot preserve the required geography, draw the verified route manually on a locked layer.
Audit the difference between design clarity and physical access
The comparison diagram shows the same garden concept with two different claims. In the misleading version, a solid green line and accessibility symbol continue over the unknown connector. In the reviewed version, that connector stays dashed with “Not verified,” while the confirmed portion is shown separately. The visual difference is not cosmetic: it changes what a visitor might believe about getting through the site.
Check color-independent status cues because color alone cannot communicate route suitability. A dashed line, visible text, and a short legend should convey uncertainty without requiring users to distinguish red from green. Inspect keyboard focus order if the mockup contains controls, and supply alternative text for the diagram. The interface can be understandable while still honestly saying that a route needs on-site verification.
Review microcopy with the site owner
Have the site contact approve gate names, opening hours, arrival directions, and any accessibility claims. Avoid writing “fully accessible” when only the first segment has been observed. Include a contact option for visitors who need confirmation before travel, but do not invent a phone number or promise individual assistance unless an approved service exists. A route alert should say exactly what is unknown rather than concealing it in fine print.
For the prototype, use fictional contact details only if they are visibly marked as placeholders and cannot escape into public materials. Keep a content checklist beside each screen: gate label, route status, effective date, and owner. A reviewer should be able to trace every noun and directional arrow to a source, not to an AI-generated image. Recheck the physical conditions before the screen goes live.
Handoff the visual design without shipping invented functionality
Google describes sharing Stitch designs and moving them through AI Studio or development tooling. The export does not automatically connect to a real route database, validate accessibility, or build a reliable navigation service. Handoff should include the source sheet, an annotated screen, component names, and a list of unresolved claims. For an interactive prototype, test taps, focus states, small-screen zoom, and screen-reader labels independently.
A developer should implement route status from approved data, not from decorative geometry in the generated page. Avoid turning a static clickable prototype into a live wayfinding promise. If the physical connector is later verified, replace the dashed status only after the owner confirms the date and conditions. Keep old variants archived to prevent a visually appealing but inaccurate state from being reused.
Release only a dated, approved version
Before public launch, compare the prototype with the current site map, walk the proposed approach with an appropriate local reviewer, and check that each route claim is backed by evidence. Save an approval record with the screen version, responsible person, and last field-check date. Test the design at realistic mobile sizes outdoors, where glare and low connectivity may affect legibility.
Stitch can accelerate exploration of a clear interface, but it cannot measure the slope or certify a path. The images in this article are original conceptual diagrams, not screenshots of Stitch or evidence that a particular garden has the routes shown. Publishing should remain blocked where critical directions or accessibility claims are unverified.
How We Research
We consulted the following named official documentation on November 4, 2026: Google Labs — Stitch design agent updates; Google Labs — AI-native Stitch design canvas. We mapped the described controls to the limited teaching scenario, then separated documented feature behavior from claims that require a physical, editorial, or permissions check. The example of community garden map prototype with Gate B, two paths and a verified route is fictional. We did not access a customer account, run live product tests, obtain real permissions, confirm a physical site, or measure software output quality. Illustrations are original explanatory diagrams of hypothetical errors and reviewed targets, never claimed as screenshots or actual model results. Product plans, interfaces, and policies may change; recheck sources and permissions immediately before use.
Frequently Asked Questions
Yes. Google describes an AI-native design canvas and an agent that works from descriptions and other context.
No. A generated interface has no authority to certify slope, surface, width, or obstacles. Verify those on site.
Not necessarily. It can be shown with a clear unverified status, as long as it is not presented as an approved route.
No. Export and handoff still require data integration, implementation, accessibility testing, and human approval.
No. The gate and route are fictional examples used to show an editorial verification workflow.