A static UI prototype should help someone make a decision. A developer may need to check whether an information hierarchy makes sense; a product team may need to compare two ways of explaining a service. The first screen matters, but a convincing prototype also includes the pages, navigation, and small behaviors that make that decision possible. A polished hero section alone cannot show whether a visitor will understand where to go next.
This guide treats a prototype as a small, complete website. It uses ordinary HTML pages, shared styles, and only the JavaScript needed for clear interactions. The workflow fits educational sites, documentation concepts, product explainers, and early interface reviews. Start with the static site planning guide if you are still deciding what the site needs to do.
Write the decision before drawing the screen
Describe the question the prototype must answer in a single sentence. For a developer resource, that might be: can a newcomer choose a relevant guide and understand the next implementation step? For a product concept, it might be: can a buyer distinguish three use cases without reading every feature? These questions give reviewers something concrete to evaluate.
Then name the primary audience, the starting point, and the desired destination. A visitor arriving from an article has different context from a colleague opening the homepage. Include both journeys if both matter. Decide what evidence will count as progress: the reviewer can locate a topic, explain the page in their own words, or complete a navigation sequence without help.
Build a page inventory with real destinations
Create a short inventory before choosing a layout. Give each page a purpose, a working title, a URL, and the next useful destination. A topic page might explain the basics and link to a detailed tutorial. An about page should explain who the material serves and how it is organized. A contact page can provide a direct email link without requiring a processing service.
Keep the first release narrow enough to finish. Five complete pages reveal more about navigation than twenty empty shells. If a topic has no distinct explanation yet, include it as a section on a stronger parent page. Split it later when the content and user need justify a separate destination.
Choose a URL convention once
For a directory-based static site, a route such as /guides/layout/ corresponds to a directory containing an index document. Use that public route consistently in menus, breadcrumbs, cards, and body links. Consistency prevents the same page from acquiring several competing addresses inside the prototype. Decide early whether the site will live at a domain root or beneath a subdirectory, because that affects asset paths.
Put meaningful content into the first layout
Write the main heading, introductory paragraph, and primary link before arranging decorative elements. Each should explain a different part of the page: what it covers, why the visitor needs it, and where to continue. Replace temporary marketing claims with statements you can support. If the concept is educational, describe the material available to read instead of suggesting that a hosted product is already operating.
Use realistic text lengths when testing cards and navigation. Include a long topic title, a short description, and an article with several paragraphs. A layout that works only with identical sample sentences will hide wrapping problems until late in the project. Content variation is a practical design input, especially on narrow screens.
Give the page a navigable structure
Use a clear main content area, recognizable navigation, and headings that reflect the relationship between sections. The W3C page structure tutorial explains how meaningful regions and heading organization support navigation, including for people using assistive technology. Treat this structure as part of the initial prototype rather than a correction to add after visual approval.
Choose links for destinations and buttons for actions. A link styled as a bright pill is still a link when it opens another page. A menu toggle is a button because it changes the current interface. Make visible text specific enough to remain understandable outside the surrounding card. “Read the deployment checklist” tells the visitor more than a row of repeated “Learn more” labels.
Define an interaction contract
List every visible control and state what happens when someone activates it. This contract can be brief: the logo opens the homepage; the menu button reveals navigation; a contents link moves to a section; an email link opens the visitor's email application. Remove controls for unavailable actions until there is a useful destination or behavior.
For a prototype of a future application, present example states as clearly labeled explanatory content. An illustrated response panel can show how an API result might be arranged without pretending a request has run. Put assumptions beside the example. Reviewers can then critique the hierarchy without confusing the demonstration with a working service.
Establish a small visual vocabulary
Choose a limited set of text sizes, spacing steps, border treatments, and surface colors. Assign each a role. A strong accent can identify the main action, while a quieter surface can contain supporting details. Reuse the same card padding and heading spacing across pages so that variation in content remains easy to scan.
Bright colors can coexist with readable content. Keep long paragraphs on calm surfaces, use saturated accents for bounded areas, and check the actual foreground and background combinations. A decorative border should frame the content without competing with it. The design mockup guide offers a useful place to plan these visual decisions before expanding the page family.
Review narrow screens as complete journeys
Start a mobile review at the homepage and follow the same route a visitor would take. Check that the sticky header leaves enough room for content, that the menu can be closed, and that long headings wrap naturally. Open an article, follow an internal link, return with browser history, and reload the destination directly. A screenshot cannot reveal all of those behaviors.
Also inspect the page at increased text size. Look for clipped navigation, fixed-height cards, and labels that disappear behind icons. Give images dimensions so their place in the layout is established. Keep tables and code examples from forcing the entire page sideways; give the specific wide element its own scrolling treatment when necessary.
Make the export the thing you review
Review a copy of the exact output directory that will be deployed. An editor preview may supply conveniences that the final host will not. Serve the exported files through a local static server, open nested routes directly, and inspect the browser's request log for missing assets. Confirm that the stylesheet is included and that the site does not require a development compiler after extraction.
Keep the archive root deliberate. The homepage index document, page directories, assets, and discovery files should appear immediately when the archive is opened. Avoid an extra project folder if the intended workflow is extraction into a public directory. The website implementation overview connects these packaging choices to the rest of the site architecture.
Use a release checklist tied to failure
- Open every destination from navigation and from a direct address, including the deepest article route.
- Use only the keyboard to open the mobile menu, follow links, and reach the footer.
- Check image files, visible descriptions, page titles, and canonical addresses against the page inventory.
- Extract the final archive into a fresh directory and confirm that it contains everything the pages request.
- Record any deliberate prototype limitation in the review notes so the next developer understands the boundary.
These checks target different risks: missing files, inaccessible controls, inconsistent content, packaging mistakes, and misunderstood scope. Repeat the relevant check after a change rather than restarting an elaborate test routine for every copy edit.
Conclusion: record a decision and a maintainable handoff
End the prototype review by recording what the team learned, which page relationships were accepted, and which uncertainty remains. Preserve the content inventory alongside the project so later changes have context. A useful prototype leaves both a working site and a clearer decision. When a backend becomes necessary, use the framework boundary guide to plan that next step without losing the interface work.
