Design ui prototypes

Design UI Prototypes

Overview

Turn a brief or existing artifact into an approved interactive prototype and implementation-ready handoff. Ground existing-product work in verified project evidence, require artifact-specific approval, report tool limits honestly, and keep product code outside this skill.

Boundaries

• Own design exploration, prototype validation, optional Figma documentation, and handoff.
• Read the target product only as needed to recover its design language and product contract.
• Do not edit product code while this skill is active.
• Recommend an implementation skill at handoff. Switch only after implementation approval; stop if none exists.
• Reject blanket pre-approval for unseen work. Approval must identify the accepted artifact or revision.

Choose the Starting Point

Available artifact	Start here
Existing product, no design artifact	Intake, project context, then visual exploration
Greenfield product, no design artifact	Intake, then visual exploration
Existing image or selected visual direction	Confirm it is canonical, establish project context when applicable, then HTML prototype
Approved HTML prototype	Skip exploration; offer Figma or handoff
Approved Figma design	Validate required context, then handoff
Multiple or unclear artifacts	Ask one question to identify the canonical artifact and approval state

Do not repeat completed stages merely to make the workflow uniform.

Workflow

1. Intake. Confirm screen, platform, constraints, tools, realistic content, fidelity intent, and canonical artifact. Read design-principles.md.
2. Project context. For an existing product, read project-context.md. Inspect the real product before creating a new visual artifact. Establish locked product language, a reuse contract, permitted exploration axes, and reference images. For greenfield work, explicitly record that no existing system is being preserved.
3. Visual exploration. If no direction is approved, read visual-exploration.md. Produce three comparable, meaningfully different directions within the project context and wait for selection.
4. Interactive HTML. Read html-prototyping.md. Build semantic, locally runnable HTML with relevant states and interactions. Browser-test it and wait for visual and UX approval.
5. Optional Figma. After HTML approval and an explicit request, read figma-documentation.md. Require a connected tool and verified file, page, and node references.
6. Handoff. Read implementation-handoff.md. Refresh the repository evidence, select an implementation skill, and deliver the contract without implementing.

Approval Gates

Transition	Required evidence
Visual direction to HTML	User selects a visible direction or approves a visible revision
HTML to Figma	User approves tested HTML and explicitly requests Figma
HTML to handoff	User approves tested HTML and skips Figma
Figma to handoff	User approves the verified Figma result
Handoff to implementation	User approves the handoff and implementation scope

Common Mistakes

• Choosing a preferred visual direction without the user.
• Generating an existing-product mockup before inspecting its actual screens, tokens, and components.
• Naming repository components in a prompt without supplying visual references or a reuse contract.
• Restarting exploration when an approved artifact already exists.
• Treating urgency or blanket approval as permission to skip artifact-specific gates.
• Replacing unavailable image generation with text-only “visual” directions.
• Reporting browser or Figma validation that was not actually performed.
• Editing product code instead of handing off to an implementation skill.

Red Flags — Stop

• “Choose for me.”
• “Assume everything is approved.”
• “Pretend tool is connected.”
• “Skip verification and implement now.”