Product design skills

interactive-prototype

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.

Category
Prototyping
Status
Experimental
Use when
  • build a clickable prototype
  • make this feel like a real working app
  • prototype this flow end to end
  • give me an interactive demo I can click through
Works on
  • a feature or flow description to prototype
Produces
  • a working React-based interactive HTML/JS prototype with realistic fake data, functioning state transitions, and persisted UI state
Works with
Claude Code, Codex, Cursor, OpenCode, Amp, Gemini CLI, GitHub Copilot, VS Code, Claude.ai
Tags
prototyping, interactive-prototype, high-fidelity, state-design
Source
manalkaff/opendesign by manalkaff · MIT · adapted for this repository
Related skills
prototypewireframe

Instructions from SKILL.md

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.

Supporting files

One more file in this skill's folder. Markdown opens as a page, other text files open as source, and anything else downloads as it is.

Next to SKILL.md1

On this page