Decide what the page must help you learn
Do not begin with the broad question “Is this page good?” Choose one uncertainty that matters to the release. Can a new visitor explain who the product is for? Can they identify the main task it supports? Do they understand whether the product is available now? Can they locate and complete the primary action? A specific question makes feedback easier to interpret and gives the team a reason to change a particular section.
Write the intended answer before testing. For example: after a brief scan, the target visitor should be able to describe the audience, the problem, and the next step in their own words. This is a working criterion, not a universal score. If a key limitation must be understood, include it in the criterion. Avoid optimizing for a response the team merely hopes to hear.
Keep the test proportional. A review with a few people can reveal confusing language or a broken path, but it cannot establish how a whole market will respond. Record who took part, what context they saw, and what the test did not cover. If access to representative visitors is unavailable, do a structured internal review and mark that limitation rather than treating teammates as equivalent to customers.
Test message comprehension
Give the person a short task: look at the page as if they have encountered the product for the first time, then explain what they think it does, who might use it, and what they would do next. Let them read without narrating every element for them. If they get stuck, note the exact wording or section where they pause. Do not lead with an explanation of the product, because that can mask a page problem.
Ask what they believe the product can do and what they think is outside its scope. Compare those answers with the current release boundary. A mismatch may mean the page overpromises, the product boundary is unclear, or the person's context differs from the intended audience. Record the observation first and discuss possible causes afterward.
Check whether the proof is understandable. Ask what the screenshot, example, quotation, or process description demonstrates. If the person assumes a mockup is a working product, label it more clearly. If a claim has no visible support, decide whether the team can add accurate evidence, narrow the wording, or remove it. Do not create a proof point solely to make a section look complete.
Exercise the primary action
Use the page in a realistic device and browser context. Ask the person to complete the intended next step without coaching. Observe whether the button is visible, whether the label describes the result, whether form fields make sense, and whether the confirmation screen tells them what happens next. A click test that ends before the request is received is incomplete; check the actual handoff to the team as well.
Test alternative states: required field missing, invalid input, slow response, duplicate submission, or an access step that is unavailable. Select relevant cases rather than mechanically testing every theoretical possibility. Confirm that errors are understandable and that the visitor can recover. If the action has consequences, make sure the page communicates them before submission.
Review the page on a phone and with keyboard navigation. Check that headings, links, inputs, and buttons are understandable and usable without relying only on color or a pointer. Make sure important text and the primary action remain available at different viewport sizes. If accessibility needs specialist review, identify that as a separate review item instead of implying that a quick pass certifies accessibility.
Inspect the claim and evidence trail
Create a short table of public claims, the evidence behind each one, the owner who can confirm it, and any approval needed. Check product descriptions against the current build and verify that customer examples or quotations are approved. Make clear whether an image is a current product view, a prototype, or an illustration. Remove claims that cannot be substantiated in time for the release.
Read the page as a skeptical visitor. Are the audience, task, product behavior, limitations, and next step clear? Does a claim imply a result, integration, or service level that the team has not confirmed? Are dates and availability current? Check page links and form destinations. An accurate headline can still frustrate visitors if the next click leads to an outdated or inaccessible route.
Review the words that can be misunderstood. “Automated,” “AI-powered,” “secure,” or “instant” may imply specific behavior to a reader. Describe what the product actually does and what role the user has. Avoid technical language where a plain description will do, and define specialized terms where the audience needs them.
Record observations and make a revision decision
Use a compact note for each session: the test question, participant context, task, observed behavior, exact point of confusion, and the team's interpretation. Keep observations separate from explanations. For instance, “the person searched below the fold for an access explanation” is observable; “the person is not a qualified prospect” is a hypothesis that requires support.
Group repeated issues by their effect on the intended decision. A misunderstanding of the core promise may justify revising the opening section. A form error may require a technical fix. A question about a secondary detail may call for a concise FAQ or an existing supporting page. Avoid changing everything after each comment; prioritize issues that prevent the intended visitor from understanding or taking the promised next step.
After revision, rerun the task that exposed the problem. Record what changed and whether the person could now complete the task or explain the offer. If findings conflict, preserve the disagreement and inspect differences in context. Do not average away a serious misunderstanding or present a small qualitative review as a quantified conversion result.
Plan a post-launch review
Pre-launch review checks whether the page can perform its intended job; post-launch review examines actual behavior in context. Define which signals are appropriate and available, who can view them, and what decision they can inform. A page view or button click does not by itself explain motivation. Pair observed behavior with support questions or direct feedback when that is appropriate and permitted.
Set a date to check whether the page remains accurate as product availability and behavior change. Assign an owner for copy, proof approvals, and the action path. Record open questions and changes so the next reviewer knows what was tested. If the page changes materially, revisit the relevant message and interaction checks.
Questions founders ask
How do I test a landing page before launch?
Choose a specific question, give an unfamiliar target reader a realistic task, observe what they understand and do, inspect the full action path, and record limitations. Revise the sections that block comprehension or the promised next step, then repeat the relevant task.
How many people do I need to test a product page?
There is no single count that proves a page works for every audience. A small review can uncover usability and wording issues; document who participated and avoid treating those observations as a representative market estimate.
Does a landing page test prove demand?
A page test can help evaluate comprehension and the action path. Demand requires evidence suited to the audience, offer, and behavior being studied. Do not treat clicks, compliments, or a small convenience sample as proof by themselves.
Claim sources
| Claim | Source |
|---|---|
| GCG's Launch Strategy scope includes positioning, conversion pages, analytics, content, and launch execution. | Live Launch Strategy page, fetched 2026-11-10. |
| GCG's Venture Prototyping page describes a product expression and proof path. | Live Venture Prototyping page, fetched 2026-11-10. |
| The review tasks and interpretation limits are editorial recommendations, not measured outcomes or market findings. | Editorial guidance; no outcome or performance claim. |