HTML mockup design: share a mockup as a link

By NOS Team · Updated Nov 8, 2026 · 6 min read

We made a fictional equipment-rental screen to test one question: can a reader choose a kit and understand the pickup summary on a phone? The page uses fixed sample content, two working choices, and a visible draft banner. It does not save a reservation or collect payment.

Download the complete fictional example

What should an HTML mockup design prove?

A mockup is a styled draft, not a smaller version of the finished product. Start with a decision the screen must support. Our question was visible at the top of the example, so the person opening it knew what to check.

The first pass kept the layout, phone behavior, fixed sample data, and selection result. Account access, inventory, payment, and storage were outside the test. Cutting those systems made the example honest about what worked.

How do you turn the HTML into a mockup link?

1. Keep the example in one file. Put the layout, styles, and interaction together so no local folder is needed.
2. Open the page in View. Read the draft marker, review question, longest text, and primary choice at the size a reviewer will use.
3. Create the reader link. Open Share and copy the address from that panel.
4. Open the copied address separately. Do not treat the editor preview as proof that a reader can open it.

Does the mockup work on a phone?

The public address opened at 390 pixels wide with one card per row. The draft banner and review question remained above the first choice. That mattered because the same content used two columns in the wider layout.

We pressed Choose studio kit on that public page. The screen moved to a pickup summary with the chosen kit, a fictional collection window, and an estimated total. No reservation was sent anywhere.

Completed state: the shared mockup answered its review question. A reader could make one choice and see the resulting summary within the same page.

What failure states should a mockup show?

Our example deliberately stops before a real transaction. The note below the cards says that nothing is saved and no payment is collected. That is a boundary, not missing polish.

For a form mockup, show an empty required field or a rejected value as fixed content if the review question is about error wording. Do not imply that a backend exists. For a loading problem, include a clear retry state rather than a spinner that never ends.

Mobile check: if a button, heading, or long label falls outside the phone viewport, change the mockup before sharing it. A desktop screenshot cannot settle that question.

How do you revise the same mockup link?

The first headline was “Pick a kit for the weekend.” We opened Edit on the existing page, selected that heading, replaced it with “Choose a kit and check pickup,” and finished the edit. The edit kept the original reader address.

We reopened the original public address. It displayed the new headline, so the next review round did not need another link.

What should you build and what should you fake?

Build the parts that answer the review question: layout, spacing, responsive behavior, the important navigation, and the state reached by the main action. Use realistic fixed rows and labels so the design has to hold real text lengths.

Fake the parts outside that question. A static confirmation can stand in for storage. A fixed warning can stand in for validation. A dead settings link is acceptable when settings are not being reviewed. Label those limits so nobody mistakes a convincing screen for a working service.

Use awkward sample content

• Include the longest realistic title or name.
• Include a missing value and an empty state when the layout must support them.
• Use a number wide enough to test the column.
• Show a useful error message if recovery is part of the review.

Mockup, wireframe, or prototype?

An HTML wireframe settles structure and content order with minimal styling. A mockup adds the intended visual direction and realistic content. An HTML prototype goes further when the question depends on a larger interaction.

Choose the lightest artifact that can answer the question. If the issue is the order of sections, use a wireframe. If it is whether the finished-looking screen holds real content, use a mockup. If someone must complete a multi-step task, use a prototype.

How should you ask for feedback?

Send the link with two specific questions. For this example they could be: “Is the pickup summary clear after you choose a kit?” and “Does any important information disappear on a phone?” Those questions keep the review on the path the mockup can actually demonstrate.

Add the round and date to the draft itself. If the link is forwarded, the next reader can still see that it is not the finished service.

For a client handoff, see how to send a prototype without an account wall.

When not to do this

Using NOS for a mockup link

In this example, NOS displayed the one-file HTML in Code and View, created a reader address in Share, and kept that address after we changed the headline in Edit. The public page also ran the mockup’s choice button. These observations apply to the fictional page shown here; they do not turn its fixed data into a backend.