Mockup¶
Artifact — instantiates Rapid Prototype Learning Loop
A simplified visual or structural representation of a proposed design.
A mockup is a resolved, static representation that shows what a design will look like without doing anything it will do. Its defining move is a deliberate fidelity split: visual and structural fidelity are raised to a presentational, near-real level while functional fidelity is held at zero. The design question is assumed already chosen — a mockup is not for discovering what to test, but for putting a concrete, high-resolution look in front of the specific people whose reactions matter, so a room can align on appearance, layout, and comprehension before anything expensive is committed. The mockup is shown, not operated. That is what separates it from every sibling a user actually drives.
Example¶
A cereal brand is redesigning its box. The team produces high-fidelity flat mockups of the new front-of-pack — three color systems, a new logo lockup, and a "no artificial colors" callout in different positions — and prints them at true size. They stand the printed panels on a mock shelf beside real competitor boxes and walk three brand managers, a retail category buyer, and a handful of shoppers past it. The reactions are about the look: the buyer flags that the callout collides with the zone where the retailer's own shelf-tag sits; two shoppers misread the "family size" flag as a new flavor; the managers split on whether the muted palette still reads as "the brand" from six feet away.
Each reaction, and the decision it drives, goes into a shared log — callout moves up-left, "family size" flag gets a size icon, palette test at distance scheduled. Nothing in the session was interactive; no one bought or opened a box. The outcome is alignment on one direction plus a recorded punch-list of look-and-layout fixes, all before the brand spends on die-lines, photography, and print plates.
How it works¶
- Split the fidelity on purpose. Push visual and structural realism up to "looks nearly final" while keeping behavior at zero, so attention lands on appearance and layout rather than function.
- Present in a realistic frame. Show the mockup where the real thing will live (on-shelf, on-page, in-hand) so reactions are to the design in context, not in a vacuum.
- Gather from the right people. Put it in front of the specific stakeholders and users whose sign-off or comprehension actually gates the project.
- Log reaction to decision. Capture each reaction and the resulting call so the alignment persists past the meeting and doesn't have to be relitigated.
Tuning parameters¶
- Visual fidelity level — sketch-adjacent greybox up to photoreal; higher fidelity earns credible reactions but also higher false confidence and cost.
- Presentation realism — a slide vs. a true-scale print on a real shelf; more realism sharpens comprehension signals but is slower to produce.
- Stakeholder mix — who is in the room (decision-makers, end users, gatekeepers); the wrong mix produces confident agreement about the wrong thing.
- Capture structure — freeform notes vs. a reaction rubric; structure improves the learning record but can flatten unexpected responses.
When it helps, and when it misleads¶
Its strength is cheap alignment on look, layout, and comprehension: a shared, concrete object that de-risks aesthetic and brand debates and lets a group commit to a direction on something they can all see.
Its failure modes come straight from the polish. High visual fidelity breeds false confidence — people read "looks finished" as "is nearly finished." And a realistic mockup invites bikeshedding: stakeholders fixate on trivial, easy-to-judge visual details (a shade of blue, a comma) while the substantive concept goes unexamined, because arguing about the paint is easier than arguing about the structure.[1] A static mockup also simply cannot reveal whether a flow works — it shows the destination, never the journey. The guarding discipline is to state out loud which fidelity is faked versus real, steer feedback to the decision actually on the table, and refuse to let a mockup stand in for an interaction test.
How it implements the components¶
prototype_fidelity— the mockup is a fidelity decision made visible: visual and structural realism deliberately raised, functional realism deliberately zero.participant_or_stakeholder_sample— it is built to be presented to a chosen set of stakeholders and users whose reactions to the look gate the next commitment.learning_record— reactions and the decisions they drive are logged so alignment survives the meeting.
It does not implement risky_assumption or design_hypothesis — choosing and framing the question is the Sketch's upstream job, and the mockup assumes the direction is already set. Because it is static, it also owns no test_context or feedback_signal from a user operating it — those belong to the Paper Prototype.
Related¶
- Instantiates: Rapid Prototype Learning Loop — the mockup is the loop's alignment step, resolving and presenting a chosen direction.
- Consumes: Sketch supplies the framed direction the mockup resolves into a presentable look.
- Sibling mechanisms: Sketch · Paper Prototype · Rough Physical Model · Clickable Prototype · Service Walkthrough · Small-Scale Pilot · Wizard-of-Oz Test
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Mockup operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it a simplified visual or structural representation of a proposed design.
Independent corroboration: The frozen evidence defines Mockup as 'A simplified visual or structural representation of a proposed design', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Representation, Specification & Plan — The mockup is a representation, but it is deliberately presented in context to users to generate decision evidence.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Simplified representations built to inspect and revise a proposed design are a long-standing engineering and industrial-design practice.
Related originating lineages:
- Architecture & Urban Planning — Architectural drawings and physical models independently established mockups as pre-construction representations.
- Human-Computer Interaction — Interface design materially developed low- and high-fidelity screen mockups for user testing.
Review resolution: Both independent reviews agree on primary origin engineering_design; reconciliation resolves secondary fields (reported_ambiguity, domain_reach_disagreement). Alternate origins retained (architecture_urban_planning, human_computer_interaction) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=convergent records the historical relationship among lineages. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=false preserves either reviewer's finding that the encyclopedia generalized the mechanism.
Attribution caveat: Mockups long predate any one modern design discipline.
Review outcome: Reconciled after independent review; medium confidence.
References¶
[1] Parkinson's law of triviality, named for C. Northcote Parkinson (1957): a group will spend disproportionate time on trivial, easy-to-grasp items (his example: bickering over a bike shed while waving through a nuclear plant) — later nicknamed "bikeshedding." A polished mockup is a classic trigger, because a font choice is far easier to have an opinion about than the design's structure. registry ↩