6.1 KiB

Raw Blame History

Freya's Interactive Prototyping Guide

When to load: When creating HTML prototypes or interactive mockups

Core Principle

HTML prototypes are THINKING TOOLS, not final products.

Prototypes let users FEEL the design before we commit to production code. They reveal gaps in logic that static specs might miss.

Why HTML Prototypes?

Static Specs Can't Show

❌ How it FEELS to interact
❌ Where users get confused
❌ What's missing in the flow
❌ If the pacing feels right
❌ Whether copy actually works

HTML Prototypes Reveal

✅ Interaction feels natural or awkward
✅ Information appears when needed
✅ Flow has logical gaps
✅ Users understand next steps
✅ Content triggers emotions

Prototypes as Validation

Think of prototypes as:

Thinking tools - Help us understand what we're building
Communication tools - Show stakeholders/users the vision
Validation tools - Catch problems before coding
Specification supplements - Demonstrate what words can't

NOT:

❌ Production code (that's Phase 4 → BMM handoff)
❌ Pixel-perfect mockups (that's Figma's job)
❌ Final design (they're meant to evolve)

When to Create Prototypes

Always Create For

Complex interactions (multi-step forms, wizards)
Novel UI patterns (users haven't seen before)
Critical flows (signup, purchase, onboarding)
Content-heavy pages (validate information hierarchy)

Optional For

Simple pages (standard layouts)
Repetitive patterns (once validated, reuse)
Admin interfaces (if similar to known patterns)

When in doubt → Prototype. 30 minutes of HTML saves hours of rework.

Prototype Fidelity Levels

1. Wireframe Prototype (Fastest)

Basic HTML structure
Placeholder content
No styling (browser defaults)
Focus: Information architecture

Use when: Testing flow logic only

2. Interactive Prototype (Standard)

Structured HTML
Actual content (multi-language)
Basic CSS (layout, spacing, typography)
Interactive elements (buttons, forms, navigation)

Use when: Validating user experience

3. Design System Prototype (If Enabled)

Component-based HTML
Design System classes
Design tokens (colors, spacing)
Real interactions

Use when: Phase 5 (Design System) is enabled

Using Design System Components

If Design System Enabled (Phase 5)

Check first:

Does this component exist in the Design System?
If yes → Use it
If similar → Assess opportunity/risk of creating variant
If no → Mark for future extraction

In prototype:

<!-- Reference existing component -->
<button class="ds-button ds-button--primary">
  Sign Up
</button>

<!-- Or note for future -->
<!-- TODO: Extract as ds-card-feature component -->
<div class="temp-feature-card">
  ...
</div>

If Design System Disabled

Use page-specific classes:

<!-- Page-specific, won't be reused -->
<button class="landing-cta-primary">
  Sign Up
</button>

Developers know: No design system = implement as-is, no abstraction needed.

What to Include in Prototypes

Must Have

✅ All sections in correct order
✅ Actual content (headlines, copy, CTAs)
✅ Multi-language versions (separate HTML files or language toggle)
✅ Interactive elements (buttons, forms, links)
✅ Key states (default, hover, active, disabled)

Optional

Form validation (unless testing UX)
Backend integration (never)
Pixel-perfect design (Figma's job)
Production-quality code (it's a prototype!)

Prototype Validation Process

1. Internal Check

Click through the flow yourself
Does it feel natural?
Any confusing moments?
Missing information?
Logical gaps?

2. Stakeholder Review

Show prototype in conversation
Watch where they pause or ask questions
Note confusion points
Validate assumptions

3. User Testing (Optional)

If critical flow, test with 3-5 users
Watch, don't explain
Note where they struggle
Identify patterns

4. Iterate

Fix gaps revealed by validation
Update specification accordingly
Re-prototype if major changes

Prototype → Specification Flow

Prototypes inform specs, not replace them:

Create prototype - Think through interaction
Validate prototype - Catch issues early
Update specification - Document what works
Generate final spec - With prototype insights

Result: Specification is battle-tested before development.

Common Prototype Mistakes

❌ Over-Engineering

"Let me make this perfect production code..."

Why bad: Wastes time, misses the point
Instead: Quick and dirty is fine - it's a prototype

❌ Under-Engineering

"Just some divs with text..."

Why bad: Can't validate actual experience
Instead: Make it interactive enough to feel real

❌ Skipping Validation

"I know this works, no need to test..."

Why bad: Your assumptions might be wrong
Instead: Always validate with at least one other person

❌ Treating as Final

"This prototype IS the spec..."

Why bad: Missing critical specification details
Instead: Prototype → insights → specification

Technical Notes

File Structure

docs/C-Scenarios/[scenario-name]/prototypes/
├── landing-page-en.html
├── landing-page-se.html
├── signup-flow-en.html
└── styles.css (shared)

Basic Template

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>[Page Name] - Prototype</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <!-- Prototype content -->
  
  <!-- Note: This is a UX prototype, not production code -->
</body>
</html>

Phase 4 Workflow: ../../workflows/4-ux-design/
Design System: ../../workflows/5-design-system/
Page Specification Template: ../../workflows/4-ux-design/templates/page-specification.template.md

Show, don't tell. Let users FEEL the design before we build it.

6.1 KiB Raw Blame History