interactive-prototype

name	interactive-prototype
description	Use when the user asks for a working, clickable prototype — something that behaves like a real app rather than a static mockup. React + useState/useEffect, realistic fake data, working state transitions.

Loaded when the user asks for a working, clickable prototype — something that behaves like a real app rather than a static mockup.

Output location

Write all output files to ./opendesign/mockups/<task-slug>/. Derive the slug from the feature name (e.g. checkout-flow, settings-panel).

Role framing

The output is a prototype that feels like a real product, not a storyboard. State transitions work. Forms validate. Buttons route to something. If an interaction is visible in the UI, it actually happens.

It is still a prototype. Cut corners on backend, real persistence, and edge cases. Fake data is fine. Real logic for the happy path is required.

Stack and structure

• React with useState and useEffect for local state and effects. Keep state colocated. No global store unless the prototype genuinely needs one.
• Split the prototype into small, readable components. Files over ~400 lines get broken up.
• Inline JSX via Babel is fine for a single-file prototype. For anything multi-screen, split into per-screen component files and compose them.
• Wrap the prototype in an appropriate device or window frame — phone bezel, browser chrome, desktop window — so it reads as a product, not a web page.

Required interaction surface

• Hover states on every interactive element.
• Click and tap handlers that route to the next state. No dead controls.
• Form validation on the happy path: buttons disabled until inputs are valid, visible error states when they are not.
• Animated transitions between states and screens. Short, purposeful, not decorative.
• Multi-step flows work end to end. The user can walk the intended happy path without hitting a dead end.
• Loading and empty states where the real product would have them. Do not skip straight to populated views.

Realism rules

• Realistic fake data. No lorem ipsum. No "John Doe." Names, copy, numbers, and timestamps fit the product's world.
• Mobile frames: hit targets minimum 44px.
• Persist critical state — current screen, active tab, demo playback position — in localStorage so a refresh during iteration does not lose the user's place.

What to leave out

• Real authentication, real network calls, real persistence beyond localStorage.
• Production-grade accessibility audits. Basic semantics and focus management are enough.
• Every possible edge case. Pick the paths the user wants to demonstrate and make those watertight.