design-prototyping

source	shipped
name	design-prototyping
description	Use when UI or interaction ideas need throwaway visual prototypes before implementation decisions are locked
type	colony
domains	["design","prototyping","ui","ux","visual-exploration"]
agent_roles	["architect","scout","oracle"]
workflow_triggers	["discuss","plan"]
task_keywords	["design","sketch","prototype","variant","mockup","interaction"]
priority	normal
version	1.0

Design Prototyping

Purpose

Multi-variant design prototyping through throwaway HTML mockups. When you can't decide how something should look or feel, this skill generates 2-3 visual variants side by side so you can compare, react, and iterate before writing production code. Sketches are disposable -- the design decisions survive, the throwaway HTML does not.

When to Use

• Multiple UI directions exist and you need to see them to decide
• A feature's interaction pattern is unclear -- "should it be a modal, an inline expand, or a separate page?"
• Stakeholders need to see something tangible before they can give feedback
• You want to test whether a layout works before building the real thing
• A design concept needs to be communicated to the team for alignment

Instructions

1. Frame the Design Question

Every sketch session starts with a design question -- not a feature spec. The question defines what you're exploring.

Good design questions:

• "How should users navigate between projects -- sidebar, tabs, or breadcrumb?"
• "Where does the notification panel live -- top bar, slide-out, or floating?"
• "How do we show loading states -- skeleton, spinner, or progressive reveal?"

Sketch card format:

## Sketch: {name}

**Design question:** {what you're deciding}
**Context:** {where this lives in the product}
**Constraints:** {fixed requirements -- must support mobile, must fit in sidebar, etc.}
**Variants:** {2-3 approaches to compare}

2. Generate Variants

Create each variant as a standalone HTML file in sketches/{name}/:

sketches/{name}/
  README.md            design question, variant descriptions, decision
  variant-a.html       first approach
  variant-b.html       second approach
  variant-c.html       third approach (optional)
  shared/              shared CSS/images if needed

Variant rules:

• Each variant must be a complete, self-contained HTML file (open in browser, works immediately)
• Use inline CSS -- no external dependencies, no build step
• Responsive: include a viewport meta tag so it works on mobile
• Visually distinct -- variants should feel genuinely different, not just color swaps
• Functional enough to click through the key interaction
• Annotated with comments explaining the design rationale

Variant dimensions to explore:

Dimension	Options
Layout	Sidebar, top nav, split pane, full-page, overlay
Density	Spacious, compact, dense data
Interaction	Click-driven, hover-driven, drag-and-drop, keyboard-first
Navigation	Drill-down, flat, wizard, tabs
Feedback	Subtle, prominent, animated, static
Tone	Playful, professional, minimal, rich

3. Present for Comparison

When presenting variants, frame the trade-offs clearly:

## Variant A: {name}
**Approach:** {one-line description}
**Strengths:** {what it does well}
**Weaknesses:** {what it sacrifices}
**Best for:** {when this variant shines}

## Variant B: {name}
{same structure}

## Variant C: {name} (if applicable)
{same structure}

Ask the human to react emotionally first, then analytically:

1. "Which one made you go 'oh nice'?"
2. "Which one would frustrate you after using it for a week?"
3. "Is there a variant you like parts of that could combine with another?"

4. Iterate on Selection

Once a direction is chosen (or a combination), iterate rapidly:

• Round 2: Refine the chosen variant with specific feedback
• Round 3: Polish details -- spacing, colors, edge cases
• Final: Produce the design reference that implementation will follow

Each iteration replaces the previous file. No version history needed -- this is a sketchpad, not a museum.

5. Package Design Decisions

When the sketch converges on a direction, capture the decisions:

# Design Decision: {feature}

## Chosen Direction
{description of the selected approach}

## Why This One
{reasoning based on comparison and feedback}

## Design Specifications
- **Layout:** {specifics}
- **Interaction pattern:** {specifics}
- **Responsive behavior:** {specifics}
- **Color and typography:** {specifics}
- **Edge cases handled:** {list}

## What We Rejected and Why
| Variant | Why Not |
|---------|---------|
| A | {reason} |
| B | {reason} |

## Reference Sketch
{path to the final HTML file}

## Implementation Notes
{anything the builder needs to know that isn't obvious from the sketch}

Key Patterns

The Contrast Principle

Variants should represent genuinely different philosophies, not minor variations. If Variant A is "sidebar navigation," Variant B should be "top tabs" not "sidebar with different icons."

The Emotional First Pattern

People know what they like before they know why. Ask for gut reactions before analytical evaluation. The emotional response reveals the real requirement.

The Frankenstein Allowance

It's valid to say "I like A's layout but B's color scheme." Combine freely -- sketches are cheap.

The Mobile-First Check

After choosing a direction, always sketch how it collapses on mobile. Many beautiful desktop designs become unusable on small screens.

The Edge Case Snapshot

Before finalizing, sketch at least one edge case: empty state, error state, or maximum-content state. These often reveal layout problems that the happy path hides.

Output Format

• Writes HTML variants to sketches/{name}/
• Produces design decision document as sketches/{name}/DECISION.md
• Returns summary and file paths to the conversation

Examples

Example 1: Navigation design

Human: "Not sure how to organize the settings page -- there are 12 sections."
Sketcher: Framing sketch: "How should users navigate 12 settings sections -- sidebar list, grouped tabs, or accordion panels?"
Generating 3 variants in sketches/settings-nav/...
  variant-a.html -- Sidebar with grouped sections
  variant-b.html -- Tab groups with sub-sections
  variant-c.html -- Accordion panels with search
Open each in your browser and tell me which feels right.

Example 2: Data display

Human: "We need to show real-time metrics but I don't want a boring dashboard."
Sketcher: Framing sketch: "How should real-time metrics feel -- status-bar glance, immersive dashboard, or ambient background?"
Generating variants in sketches/metrics-display/...
  variant-a.html -- Minimal status bar with sparklines
  variant-b.html -- Full dashboard with cards and charts
  variant-c.html -- Ambient background that shifts color with metrics
Which one matches the experience you're imagining?

Example 3: Iteration

Human: "Variant A is closest, but the sidebar feels too wide and I want the search at the top."
Sketcher: Iterating on Variant A -- narrowing sidebar to 200px, moving search to top with auto-focus...
Updated sketches/settings-nav/variant-a.html -- take a look.
Also generated the mobile collapse view: variant-a-mobile.html