Prototype Interface

Prototype Interface

A prototype is a testable hypothesis about hierarchy and interaction, not a collection of attractive screens.

Visual-target gate

1. Inspect the product’s existing UI, tokens, components, assets, and representative flows.
2. If an authoritative screenshot, design file, brand system, or selected direction exists, use it as the visual target.
3. If the work is greenfield and no target exists, generate exactly three image-based directions that differ in layout composition, typography, density, color behavior, and visual voice. Label them A, B, and C with a short rationale and tradeoff.
4. Show the three directions together and wait for the user to select one. Do not build the interface before selection.

Text-only mood boards do not satisfy the gate.

Greenfield stop contract

When no visual target exists, the current invocation ends at the selection gate:

• Persist exactly three inspectable direction artifacts in the workspace. A conversation-only image or a claim that directions are "shown above" is not evidence.
• Prefer one self-contained SVG or HTML concept board per direction when an image tool cannot save its output locally. Capture PNGs only when the available renderer can do so reliably.
• Name or caption every artifact as Direction A, Direction B, or Direction C. Reference the artifact paths in the final response.
• Render one overview containing all three directions if the tools support it, using a single batch or browser session.
• Do not create the product app, prototype flow, state matrix, or implementation scaffold before selection. Do not begin any step in the prototype workflow below.
• Once the three artifacts, rationales, tradeoffs, and selection request exist, stop. Optional polish is not a reason to continue working.

Prototype workflow

1. Define the user task, entry state, success signal, and critical decision points.
2. Map the shortest complete flow and its alternate or failure routes.
3. Write a state matrix before styling.
4. Build semantic structure and interaction using the selected design language.
5. Use realistic content, including long, empty, invalid, and localized examples.
6. Implement keyboard behavior, focus management, labels, announcements, target sizes, contrast, zoom, and reduced motion.
7. Capture the prototype at agreed narrow and wide viewports.
8. Compare expected and actual at the same browser, scale, theme, data, fonts, and motion state. Preserve expected, actual, and diff.
9. Test the critical flow as a user, then revise until no material visual or interaction mismatch remains.

State matrix

| Surface | State | Trigger | Visible response | Keyboard/focus | Evidence |
| --- | --- | --- | --- | --- | --- |

Quality rules

• Wireframes must still establish hierarchy, content, and interaction.
• Do not hide weak layout behind gradients, glass, illustrations, or excessive cards.
• Avoid placeholder text where content length affects design.
• Treat overflow, clipping, unexpected wrapping, inconsistent spacing, and fallback fonts as failures.
• Report browser rendering context because visual snapshots are environment-dependent.

Evidence packet

Before selection, return the three local artifact paths, rationales, tradeoffs, one recommendation, and a request to select A, B, or C. After selection, return target selection, flow and state matrix, runnable prototype path, test instructions, viewport matrix, expected/actual/diff artifacts, accessibility checks, and unresolved product or visual questions.