Website Mockup vs Prototype vs Live Website: What Clients Can Review

A client opens a design link and clicks the menu. Nothing happens. Is the design broken, or is the link only a visual preview? That question comes up because “mockup,” “prototype” and “website” are often used as if they mean the same thing. They describe different stages, and each stage answers different questions.

Before a review begins, identify what the client is looking at. That one sentence prevents visual decisions from getting mixed up with behavior that has not been built yet.

What a website mockup shows

A mockup is a visual representation of a page or screen. It can show layout, color, typography, imagery, content hierarchy and responsive compositions. A static mockup can be a PNG, a PDF, an exported Figma frame or an HTML presentation. Its main job is to make the intended appearance concrete.

A mockup does not automatically prove that buttons work, a form submits, the menu opens, the page is accessible to assistive technology, or the design has been implemented in code. Those behaviors need a prototype or a working build.

What a prototype adds

A prototype connects some screens or states so a reviewer can explore a proposed journey. It may let someone follow a menu, test a call-to-action path or step through a checkout concept. Prototype fidelity varies: a link between two frames can demonstrate a route without proving that the final interaction, data handling or responsive behavior is production-ready.

Ask which interactions are intentionally included and which are only represented visually. A prototype is a model for discussion, not a guarantee of final implementation.

What a live website proves

A live or staging website is implemented software. It can be tested in real browsers and devices for working links, forms, loading behavior, keyboard interaction and responsive layout. It still needs testing: a design approval does not certify the built page, and a successful build does not establish that its content or business rules are correct.

Choose review questions for the artifact

• Mockup: Does the page communicate the right offer? Is the hierarchy clear? Are the content, imagery and layout direction appropriate?
• Prototype: Can a reviewer complete the intended journey? Are labels, states and transitions understandable?
• Live site: Do links, forms and controls work? Does the page behave at agreed viewport sizes and with keyboard navigation?

Do not ask a static image to answer a functional question. Record a visual change against the mockup, and record a behavior issue against the prototype or build where it can be reproduced.

A simple review handoff

When sharing a design, state the artifact type, version, pages included, review focus, decision owner and feedback deadline. For example: “This is a static homepage mockup, version 2. Please review the headline, image direction and section order by Thursday. Buttons are not interactive in this file.”

Swelik can present a long mockup as a browser preview link. It helps clients inspect the visual artifact without downloading a large attachment; it does not turn a static mockup into a working website. See the website mockup sharing guide for the sharing workflow.

Do not let stage labels create false expectations

Different teams use these words differently, so name the exact artifact and its limits instead of relying on a label alone. A Figma file may contain static frames and a clickable prototype in the same document. A PDF may show several pages, while every page remains an image. An HTML demo may respond to clicks but use placeholder data. Describe what is actually present.

A practical handoff can state: “Visual mockup, desktop and mobile frames included, no working form or menu.” For a prototype, say which journey is linked and whether it uses real content. For staging, list browsers and test data that are ready. This lets the reviewer choose the right questions and prevents a visual review from being mistaken for product QA.

Use a stage-by-stage acceptance note

At the mockup stage, record the approved visual direction, required pages and any outstanding content. At the prototype stage, record the journeys that should be demonstrated and the interactions still represented only as visuals. At the build stage, record the tested device widths, key form outcomes, browser coverage and known defects. A short written gate gives each group a clear “done” condition.

Keep decisions connected to a version. If the mockup changes after approval, note which pages changed and whether the earlier decision still applies. This is especially useful when development has started and a late visual change could affect code that is already in progress.

Example review handoff

Artifact: desktop and mobile homepage mockup, version 3.
Review now: headline clarity, trust evidence, section order.
Not included: working navigation, form submission, live responsive behavior.
Decision owner: marketing lead.
Next gate: approve the visual direction before build estimates are finalized.

Use the same structure for any file type. It is more informative than writing only “please review the website.”

Frequently asked questions

Can a mockup be interactive?

It can be presented inside a tool with interactive controls, but the word “mockup” alone does not tell you which behaviors work. Ask what is connected and what is illustrative.

When should clients approve the design?

Agree on the approval gate in the project plan. Many teams approve visual direction before implementation, then review the built site separately for behavior and content.

Can a PDF be a website prototype?

A PDF can communicate visual pages and links, but it usually does not model the full behavior of a web interface. Describe it as a visual review document unless it contains tested interactions.