Wireframes, Mockups, and Prototypes

Before you write code, you should agree on what the interface looks like. Design artifacts—wireframes, mockups, prototypes—serve this purpose. They're also valuable for discovering problems cheaply (on paper) before discovering them expensively (in code).

The Three Types of Design Artifacts

Wireframes are low-fidelity sketches of the interface. Black-and-white boxes showing layout and flow. No design polish, no colors, no typography finalization. The goal: agree on structure before investing in design. Think: blueprint of a house, not the finished house.

Mockups are high-fidelity visual designs. Real colors, real typography, real images. They look like the finished product but aren't interactive. The goal: finalize the visual design and get stakeholder buy-in before development.

Prototypes are interactive mockups. You can click buttons, fill out forms, see what happens. They may or may not have real data behind them, but they simulate the user experience. The goal: test the interaction flow and get stakeholder feedback on usability.

When to Use Each

Use wireframes when: You're early in the project and structural questions are still open. "Where does this button go? Is this the right flow?" Wireframes are cheap to change. Don't invest in visual design until structure is locked.

Use mockups when: Structure is locked and you need to finalize design. The interface layout is done; now it needs to look professional. Mockups are where you decide colors, typography, spacing, imagery. They're more expensive to change than wireframes so wait until you're confident about structure.

Use prototypes when: You need stakeholders to understand interaction flows that are hard to explain statically. Or when you need to test usability with users before building. A clickable prototype is better than describing a feature—people can experience it.

Why Wireframes Matter

The most valuable wireframe is the one that surfaces misalignment before development starts. You put a layout in front of three stakeholders and they all imagine something different. Great—now you know you need to align before coding. If you skip wireframes and find this out during code review, you've wasted weeks.

Wireframes are also useful for developers. A wireframe doesn't have every detail of the final design, but it shows layout, flow, and hierarchy. Developers can look at a wireframe and estimate how long it will take to build.

Good wireframes show:

• Page structure and layout (header, sidebar, main content area)
• Hierarchy (what's most important, what's secondary)
• Key interactions (what happens when you click this button?)
• Content placeholders (where does text go, where do images go)
• Navigation and information architecture (how users get from page to page)

Design Handoff: Figma

The industry standard for design-to-development handoff is Figma (or Adobe XD). A designer creates the mockups in Figma, and developers use it as a specification document.

A professional Figma file for a developer includes:

• Mockups of every screen or page
• Interaction states (what does a button look like when hovered, pressed, disabled?)
• Type styles (font sizes, weights, line heights, colors)
• Spacing specifications (padding, margins, gaps between elements)
• Color palette with hex codes
• Icons and assets
• Annotations explaining non-obvious behaviors

Developers use Figma to extract measurements, colors, and assets directly. Instead of eyeballing the design, they know exactly what size things should be. This saves days of back-and-forth.

The key: design should be done (or nearly done) before development starts. If design happens during development, developers wait for design, then rework when design changes. This is the fastest way to blow through a timeline.

When to Skip Wireframes/Mockups

Simple CRUD interfaces: If you&re building a basic admin panel with standard UI patterns (tables, forms, buttons), you might not need wireframes. Everyone knows what a data table looks like.

The developer is also the designer: If one person is doing both design and development, wireframes matter less because the designer is building it.

Pattern-heavy applications: If you're building entirely from a component library (Bootstrap, Material UI, Tailwind) with standard patterns, wireframes might be overkill.

For novel or complex interfaces: Don't skip design. If users haven't seen this interface before, you need to design it well and test it.

Interactive Prototypes for Stakeholder Feedback

Non-technical stakeholders often can't evaluate a wireframe. They see boxes and say "okay, but what will it actually look like?" An interactive prototype is more useful because they can click through it and experience it.

Tools for building interactive prototypes:

• Figma: Has prototyping built-in. You can link wireframes/mockups and add basic interactions.
• Framer: Specialized for interactive prototypes with animations.
• Marvel: Simple prototype builder that works with mockups.
• InVision: Long-standing prototype tool with good feedback features.
• Balsamiq: Good for low-fidelity interactive wireframes.

A prototype can be quick (2-3 days to build) and reveals problems that static designs miss. Users say "this is confusing" when they click a button that doesn't work the way they expected.

The Feedback Loop

Wireframes: Share with stakeholders and team. Get feedback on structure. Iterate until everyone agrees on layout and flow.

Mockups: Share with stakeholders, marketing, customer success. Does it represent the brand? Is it clear? Iterate on visual design.

Interactive prototype: Test with real users if possible (or representative users). Do they understand how to use it? Do they find what they need? Iterate on interaction.

Final design in Figma: Complete handoff to developers. Incorporate all feedback. Lock it down so developers have a reference.

After this, changes should be intentional. If someone wants to change the design mid-development, you assess the impact: does this delay the timeline? Is it critical?

Common Mistakes

Skipping wireframes and going straight to mockups. This means structural problems aren't surfaced until you've spent time on visual design. Iterate on structure first (cheap) then design (more expensive).

Too many iterations without locking the design. You can iterate forever. At some point you need to say "this is the design, we're building this." Missing lock-in means design keeps changing during development.

Design doesn't match actual content. Mockups use placeholder text. Real content often doesn't fit. "Hello, John" in the mockup might need to handle "Hello, Alexander the Great." Share real content with designers so they design for reality.

Designers not considering implementation constraints. A designer might design something beautiful that requires complex animations or performance compromises. Early communication prevents this. Ask developers: "Is this implementable in the timeline?" early, not late.