Prototyping

Why Prototype

Prototypes externalize design ideas so they can be communicated, explored, tested, and refined. A prototype is a representation of a design made before the final artifact exists.

Core principle: The purpose of a prototype is to answer a question. Every prototype should have a clear hypothesis or learning objective.

The Prototype Spectrum

Fidelity:  Low ◄──────────────────────────────────► High
           Sketches    Wireframes    Mockups    Interactive    Production
                                                Prototype      Code

Cost:      Cheap ◄────────────────────────────────► Expensive
Speed:     Fast  ◄────────────────────────────────► Slow
Detail:    Abstract ◄─────────────────────────────► Realistic
Feedback:  Conceptual ◄──────────────────────────► Specific

General rule: Use the lowest fidelity that answers your question. Higher fidelity is not inherently better --- it costs more, takes longer, and can anchor teams to premature decisions.

Low-Fidelity Prototyping

Sketches

Hand-drawn representations of interface concepts. The fastest way to explore ideas.

Advantages:

Extremely fast (minutes, not hours)
No tool expertise required
Low commitment --- easy to discard and redraw
Encourages focus on structure over aesthetics
Democratizes design (anyone can sketch)

Techniques:

UI sketching: Quick drawings of screens and layouts
Storyboards: Sequential sketches showing user flow through a scenario
Crazy 8s: Fold paper into 8 panels, sketch 8 ideas in 8 minutes

Sketch conventions:
  ┌─────────────────┐
  │ ▬▬▬▬▬  [Search] │  <- header with nav and search
  ├─────────────────┤
  │ ████████████████ │  <- image placeholder
  │                  │
  │ ▬▬▬▬▬▬▬▬▬▬▬▬▬▬ │  <- heading
  │ ▬▬▬▬▬ ▬▬▬▬ ▬▬▬ │  <- body text (lines)
  │ ▬▬▬▬▬▬▬ ▬▬▬▬▬▬ │
  │                  │
  │    [  Action  ]  │  <- button
  └─────────────────┘

Paper Prototypes

Physical cutouts and drawings that simulate interface interaction. A facilitator plays the "computer," swapping paper elements in response to user actions.

Process:

Draw each screen state on separate cards/paper
Prepare overlay elements for dropdowns, modals, tooltips
User "clicks" by pointing at elements
Facilitator replaces the paper to show the response
Observer takes notes on user behavior and confusion

Best for: Early-stage concept testing, testing navigation and flow, situations where speed matters more than polish.

Wireframes

Structural blueprints showing layout, content hierarchy, and functionality without visual design.

Characteristics:

Grayscale or minimal color
Placeholder text and images
Focus on spatial arrangement and content priority
No final typography or imagery

Levels of wireframe fidelity:

| Level | Content | Interaction | Use | |-------|---------|-------------|-----| | Low | Boxes and lines | None | Layout exploration | | Mid | Real labels, placeholder body text | Annotations describe behavior | Stakeholder review | | High | Near-final content | Clickable links between screens | Flow validation |

High-Fidelity Prototyping

Mockups

Static, pixel-perfect visual representations of the final design. Include real colors, typography, icons, and imagery.

Purpose:

Validate visual design decisions
Communicate exact specifications to developers
Gather feedback on look and feel
Create assets for marketing materials

Limitations: Cannot test interaction patterns, timing, animation, or responsive behavior.

Interactive Prototypes

Clickable or tappable prototypes that simulate real interaction flow. Range from click-through screen sequences to near-production simulations.

Capabilities:

Screen transitions and navigation flow
Micro-interactions and animations
Conditional logic (show different screens based on input)
Scroll behavior and responsive layouts
Form input simulation

Prototype Fidelity Dimensions

Fidelity is not a single axis. A prototype can be high-fidelity on some dimensions and low on others.

| Dimension | Low | High | |-----------|-----|------| | Visual | Grayscale, placeholders | Final design, real content | | Content | Lorem ipsum, stock photos | Real copy, real data | | Interaction | Static or basic click-through | Animations, transitions, conditional logic | | Data | Hardcoded, fake | Connected to real or realistic dataset | | Breadth | Key screens only | Full application coverage | | Depth | Happy path only | Edge cases, errors, empty states |

Prototyping Tools

Figma

Browser-based, real-time collaboration
Components with variants and properties
Auto layout for responsive behavior
Interactive prototyping with smart animate
Dev mode for developer handoff
Plugin ecosystem for extended functionality
Strength: Collaboration, all-in-one design+prototype

Sketch

macOS only, file-based
Symbols (reusable components)
Extensive third-party plugin ecosystem
Prototyping requires plugins or companion tools
Strength: Mature ecosystem, performance with large files

Adobe XD

Cross-platform (Windows, macOS)
Auto-animate between artboards
Voice prototyping support
Integration with Adobe Creative Cloud
Note: Adobe has wound down XD development as of 2024; consider alternatives

Other Tools

| Tool | Specialty | |------|-----------| | Framer | Code-based prototyping, production-ready components | | ProtoPie | Advanced interaction prototyping (sensor input, conditional logic) | | Axure RP | Complex logic, documentation-heavy, enterprise wireframing | | InVision | Screen-based prototyping, design collaboration | | Origami Studio | Meta's tool for mobile interaction prototyping | | Penpot | Open-source, browser-based design and prototyping |

Choosing a Tool

Questions to guide selection:

What fidelity level do you need?
Does the team need real-time collaboration?
What platform are you designing for (web, iOS, Android)?
Do you need advanced interactions (sensors, conditional logic)?
What is the team already familiar with?
Budget constraints?

Wizard of Oz Prototyping

A human operator secretly simulates system behavior that has not been built. The user believes they are interacting with a working system.

┌──────────┐     interacts with     ┌─────────────┐
│   User   │ ──────────────────────>│  Interface   │
└──────────┘                        └──────┬───────┘
                                           │
                                    appears automated
                                    but actually...
                                           │
                                    ┌──────▼───────┐
                                    │   Wizard     │
                                    │  (human      │
                                    │   operator)  │
                                    └──────────────┘

Use cases:

Testing voice interfaces before building speech recognition
Testing AI/ML features before the model is trained
Testing chatbot conversations before implementing NLP
Evaluating smart home interactions

Process:

Define the system's expected capabilities
Create a front-end interface the user interacts with
Wizard operates behind the scenes, generating responses
Pre-define response scripts for consistency
Record user interactions for analysis

Advantages: Test complex system concepts cheaply and early. Discover user expectations before investing in technology.

Limitations: Wizard response time may not match real system. Wizard inconsistency across sessions. Does not scale.

The Build-Measure-Learn Cycle

        Build
       /      \
      /        \
   Learn ◄──── Measure

Each prototype iteration should:

Build: Create or modify the prototype to test a specific hypothesis
Measure: Test with users, collect data (qualitative and quantitative)
Learn: Analyze results, identify what works and what needs change
Decide: Persevere (iterate on current direction) or pivot (change approach)

Managing Prototype Iterations

| Iteration | Typical Fidelity | Focus | Users | |-----------|-----------------|-------|-------| | 1 | Sketches / paper | Core concept, navigation structure | 3-5 | | 2 | Wireframes (clickable) | Task flows, information hierarchy | 5 | | 3 | Visual mockups | Look and feel, brand alignment | 5 + stakeholders | | 4 | Interactive prototype | Micro-interactions, edge cases | 5-8 | | 5 | Coded prototype / beta | Performance, real data, accessibility | 8-10 + analytics |

What to Prototype

Happy path: The ideal flow when everything goes right
Edge cases: Empty states, error states, maximum content, zero results
Onboarding: First-time user experience
Key interactions: The moments that define the product experience

Common Prototyping Pitfalls

| Pitfall | Consequence | Mitigation | |---------|-------------|------------| | Too high fidelity too early | Anchors team to a specific design | Start low-fi, increase gradually | | Prototype becomes the product | Technical debt, poor architecture | Prototype is for learning, not shipping | | Testing without clear questions | Vague, unactionable results | Define hypotheses before building | | Ignoring edge cases | False confidence in the design | Prototype error states and empty states | | Not testing with real users | Echo chamber of designer opinions | Recruit representative participants | | Over-investing in one concept | Sunk cost bias limits exploration | Explore multiple concepts in parallel |

Prototype Documentation

When handing off prototypes, include:

Design rationale: Why decisions were made (not just what)
Interaction specifications: What happens on hover, click, swipe, error
State documentation: All states of each component (default, hover, active, disabled, error, loading)
Responsive behavior: How layouts adapt across breakpoints
Animation specs: Duration, easing, properties animated
Edge cases: What happens with long text, missing data, slow connections