A redesigned site is ready for approval, or your team has finished a landing page for an upcoming campaign. Now you need to review it and send feedback before visitors arrive.
You want people to understand the offer, find what they need, and complete the main action. A page can match the approved design and still leave someone unable to send an inquiry or open the menu.
Before you go live, test your site by walking the customer’s journeys yourself. Check the forms, the phone layout and then the desktop and tablet layouts, the menus, and the key actions.
That pre-launch pass is a visual and click-through review, not a full technical website launch checklist. Your notes cover what a visitor can see and do. Specialist checks stay with the technical team, as described near the end.
Define Your Ideal Customer and the Jobs They Need to Get Done
Before judging the website, describe the customer you’re reviewing it for. Include their situation, what they already know, and what they need to decide or accomplish.
Define their goal beyond the website, too. Someone buying a car wants a vehicle that suits their life, not merely a completed inquiry form.
For a car brand, your customer might be a buyer replacing a family car within a fixed budget. They need to compare suitable vehicles, understand their options, and arrange a next step with a dealer.
For accounting software, your customer might be a small-business owner who wants to do their own books. They need to understand whether they can record expenses and send invoices without accounting expertise.
Turn those needs into questions you can use during the review. Can the car buyer judge whether a vehicle fits their needs? Can the business owner understand how the software would help them manage their books?
Keep that customer profile beside your notes. It gives you a reason to question a confusing label or missing detail beyond whether you like the design.
If you want more help defining those customers and their jobs, these three books are a practical place to start. Jerry Angrave’s The Journey Mapping Playbook: A Practical Guide to Preparing, Facilitating and Unlocking the Value of Customer Journey Mapping (2020) shows how to plan and run journey mapping workshops.
Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, and Alan Smith wrote Value Proposition Design: How to Create Products and Services Customers Want (2014). It introduces the Value Proposition Canvas for mapping customer jobs, pains, and gains.
Jim Kalbach’s The Jobs To Be Done Playbook: Align Your Markets, Organization, and Strategy Around Customer Needs (2020) is a practical guide to the jobs-to-be-done approach.
Agree on What You’re Reviewing
When your team provides a staging link, confirm that the review version will look and behave like the final production version. Ask them to identify any differences, so you don’t approve unfinished content or miss a feature that still needs testing.
Next, map the journeys your customer will take to get their jobs done. For each journey, agree on an entry point, the decisions along the way, and what successful completion looks like.
A car buyer looking for certified used cars needs a route to suitable listings and a dealer inquiry. Someone who wants to build their own car needs a route through a visual configurator to a finished specification.
A complex site can have many journeys, so agree which ones your review must cover before you begin. If time is short, review one important journey through checks one to three and mark the remaining checks as outstanding.
Before submitting anything, get approved test details and an agreed place to use them. Ask who will confirm that inquiries, bookings, or orders reach the right system or person.
Unless your team has confirmed a safe test setup, assume that submitting a form or completing a purchase will reach a real person or take a real payment. If there isn’t one, review up to submission and mark completion as untested.
Adjust the Review for a Redesign or Landing Page
Step into the customer’s shoes for both kinds of review. The difference is whether you’re evaluating all their important journeys or one focused route to a specific action.
For a Full-Site Redesign
If you’re redesigning your website, review all the customer journeys you agreed to cover, including the pages and decisions within each one. For the car brand, that means following both the certified-used-car search and the build-your-own journey.
Include existing entry URLs as well as the homepage, because customers may arrive partway through a journey. Check whether menus, search, and links to moved content still help them reach their goal.
If page addresses are changing, ask the technical team to own the migration checks described later. A manual review of a few pages cannot confirm that every old address reaches its replacement.
For a Campaign Landing Page
Treat the landing page as a focused funnel for one campaign and one specific action. For example, an accounting-software campaign might guide a small-business owner toward starting a trial, rather than exploring every product feature.
Review from the actual campaign URL and compare the page with the ad or email. Does it answer that customer’s questions and keep the offer consistent with what they were promised?
Follow the intended action through the form, confirmation, and handoff to your team. A narrower journey still needs the same care with forms, phone use, accessibility, and privacy.
1. Walk the Customer’s Journeys to Completion
Walk each agreed journey as the customer you defined, starting where they would arrive. At each decision, ask whether the page gives them enough information to take the next step.
Is it clear what you’re looking at? Are the calls to action clear, and are they positioned where the customer needs them? A car buyer should understand whether a button opens vehicle details, starts a configuration, or contacts a dealer.
Follow the journey through its agreed finish. For an information site, that might mean finding the correct opening hours or downloading the document you came for.
For a submission, check that the confirmation explains what happened and what comes next. Ask the responsible team to confirm receipt and any follow-up. A success message alone cannot show that the handoff worked.
2. Try Forms with Correct, Incorrect, and Unusual Details
Read the form before filling it in. Check whether labels, required fields, and format hints tell this customer what to provide.
Follow the fields visually and with Tab. Does the order keep related details together, or do columns make you jump around? Format requirements should be visible before an error, not revealed only after one.
In the agreed test environment, submit every form the customer is meant to use, including the contact form if the site has one. Work through three kinds of scenario for each:
- Correct details: Complete the form with approved valid details and follow the result. For a purchase, ask your team for an expected tax amount and compare it with the calculated total.
- Incorrect details: Leave a required field empty or enter an email address without an @ sign. Check whether each error identifies the problem and explains how to fix it. Look for a message beside the field, not only a color change.
- Edge cases: Agree on unusual but valid details with your team, such as a long business name. Check whether the customer can enter them and finish without changing accurate information to satisfy the form.
After an error, check whether the form preserves what you entered so you can correct it. Make sure the error remains visible while you fix the problem, then try again to confirm you can finish.
If the form includes a reset control, check whether someone could mistake it for the main action. Flag a prominent reset control that could cause the customer to lose their work.
A clear thank-you message can confirm completion. You don’t need a separate thank-you page, but you do need an unmistakable result and the delivery confirmation from step one.
W3C’s guidance on form notifications shows why both errors and success messages need to be understandable. Send unclear messages back with the exact wording and the action that produced them.
3. Read the Whole Page on Phones First, Then Desktops and Tablets
Don’t let a review done entirely on a desktop stand in for the phone experience. Marketers and agencies can miss phone problems when they judge the website only on the larger screen they work on.
Statcounter’s worldwide October 2026 split recorded mobile at 59.9%, desktop at 38.51%, and tablet at 1.59%. These are shares of page views on its tracked network, not people, and desktop includes laptops.
October was the most recent complete month shown when checked, though the figures can still be revised. That sample gives you a reason to prioritize review on mobile devices, not a prediction of your own website’s traffic.
Assume your customer’s first visit is on a phone. Before scrolling, can they understand the offer and see the information and main action they need to begin?
The device’s screen size isn’t the same as the space available to the page. Window size, menus, and browser controls affect that space, so check what’s actually visible on a real phone too.
Then review as someone continuing or returning on a desktop or tablet, especially for a more complex task. Can the car buyer still compare their options, or the business owner find the details they need before trying the software?
Online Website Previewer is free, needs no account, and shows a live page at three fixed sizes. Start with its 390 by 844 phone view, a common page size for the standard-size iPhone 12, 13, and 14.
Its desktop view is 1920 by 1080, matching the most common desktop screen resolution in Statcounter’s October 2026 worldwide tables. Its tablet view is 820 by 1180, a common page size for some iPad Air models.
The desktop ranking describes screen resolution, not a visitor’s available page space. These sizes are a starting sample, not proof that they match your audience or that every width between them works. If visitor data identifies other important sizes, ask your team to cover those separately and record what this pass leaves out.
Read each journey’s pages from top to bottom, including the phone and tablet layouts in both orientations. Look for these failures:
- Clipped text: Check headings, button labels, and form messages for missing words. Important information must remain readable, even when a label wraps onto another line.
- Overlapping sections: Look for content covering neighboring text or the next action. Check whether you can still read the offer and continue the journey.
- Distorted or unhelpful images: Check for stretching and details that become too small to understand. Text embedded in a desktop banner can become unreadable on a phone, even when the image keeps its proportions. Does the smaller image still communicate what the customer needs to know?
- Unreachable controls: Try the menu, form fields, and main action. Note any control you can see but can’t reach or use.
- Confusing phone navigation: Open the hamburger menu and check its items. Keep the customer’s most important routes near the top, rather than making them search through less relevant links.
- Intrusive headers and overlays: Scroll past the opening section and look for a sticky header that leaves too little space, blends into the page, or jumps distractingly. For banners and other elements covering content, use check six.
- Faint text and controls: Check text over images, buttons, and menu backgrounds for information that’s hard to see. Flag suspected contrast problems for assessment rather than treating a visual inspection as a measured pass.
- Missing keyboard focus: If you can’t see which link or field is selected, use the keyboard checks in step five.
- Disorienting expandable sections: Open a long accordion section and check whether you can identify where you are and reach the next choice. Flag changes that look like navigation to a different page.
- Unreadable or uncontrollable carousels: Can you read a slide before it moves, return to a previous slide, and find important information outside the carousel? Use these carousel checks where relevant, then test touch controls on a real phone.
- Content lost when enlarged: Use check seven to look for disappearing text or overlapping controls as you enlarge the page.
The previewer loads the live page inside a frame, so links, forms, and orders behave as real visits. Some sites won’t display inside a preview, even when you can open them directly.
If that happens, continue directly in your browser and on the different devices you have available. Note any sizes you couldn’t check, rather than reporting a completed comparison. These layouts don’t emulate iOS Safari or Android Chrome, so keep the real-browser checks in step five.
4. Follow Menus and Important Links
Open the menu and follow the routes visitors need for their main tasks. Try search, downloads, and contact links where the site provides them.
Check that each destination contains what the link promised. A link can open successfully and still send someone to an outdated document or the wrong service.
Open the privacy policy and other relevant policy links, including those on the landing page. Being able to reach them is a useful check, but their wording and the site’s tracking still need specialist review.
For a larger redesign, ask your team for an automated check of broken links across the site, often called a crawl. Manual sampling helps you judge destinations, but it cannot establish that every link works.
5. Repeat Important Actions with Touch and a Keyboard
Open the page directly on a real phone and repeat the main task. Try the menu, adjacent controls, and form fields with touch rather than a mouse.
Check whether the onscreen keyboard hides the field you’re completing or the next action. Try autofill where relevant, and rotate the phone to check that you can still finish.
On desktop, use Tab to move through links and controls. Check that you can see which item has focus, so you know what you’ll activate. Use Enter to follow links, and Enter or Space to activate buttons.
Try to complete the main task without the mouse. If you get stuck, record where and ask the developer to investigate. You don’t need to diagnose the code to report that the menu cannot be opened or the submit button cannot be reached.
Screen size does not tell you how someone interacts. A menu opening on mouse hover doesn’t establish that it works by touch.
The preview is a visual check in your current browser, not an iOS Safari or Android Chrome test. Agree with your team which browsers and hardware matter for your audience. Repeat critical tasks there, because different browsers can handle the same page differently.
6. Check What Banners and Sticky Elements Hide
Review the page with cookie banners, dialogs, and headers that stay in place while you scroll. Check whether they cover text, the main action, or the form’s error messages.
Scroll and use Tab with these elements visible. Can you still see the control you’ve reached, and can you continue without losing access to important content?
Try nearby small controls on a real phone. If you keep opening the wrong one, report the problem and ask the developer to check spacing and touch-target requirements.
7. Compare Final Content with the Approved Material
Read the page against the approved offer and content. Check headings, dates, contact details, button labels, and the messages shown after errors or completion.
Look for placeholder text and images, as well as old details carried over from the previous site. Confirm that visitors see the same offer throughout the journey, including the final confirmation.
Use browser zoom to enlarge the page text and try the main action again. If content disappears or controls overlap, include that in your notes so the team can investigate.
These checks overlap with W3C’s introductory accessibility checks. Passing them does not establish accessibility, so keep a broader accessibility review assigned to someone qualified.
8. Watch Someone Unfamiliar Try the Task
Ask a colleague who hasn’t worked on the website to try one of the customer’s journeys. At lunch, you could ask several people to try it and say what isn’t clear.
Give them the goal without naming the button or route. For the car example, ask them to find a certified used car within an agreed budget and work out how to contact the dealer.
Watch where they hesitate, what they misunderstand, and whether they finish without help. Use realistic tasks without clues to find usability problems your familiarity may hide.
Colleagues can help you spot confusion, but they may not represent your customers. For a high-value website or large-scale redesign, consider paid services that recruit people to test a live website:
- UserTesting offers moderated or unmoderated website tasks with recruited participants.
- Userlytics offers website studies with panel participants, including tests of beta and production sites.
- Lyssna offers live-website tasks, recordings, and panel recruitment.
Check the recruitment options and plan coverage before choosing a service. Ask which browsers and devices your proposed study can include, rather than assuming every service supports the same setup.
Ask for participants who fit the customer profile and give them the journeys you need to evaluate. Recordings or heatmaps of existing visits alone don’t replace asking recruited participants to attempt those tasks.
Keep Technical Launch Checks Assigned
Your review gives the team evidence about what visitors can see and do. Ask who owns the checks that need specialist tools or expertise, so they don’t disappear between approvals.
- Accessibility: Request a broader assessment, including checks beyond the introductory keyboard and zoom review.
- Performance: Ask the technical team to check loading speed and how quickly the page responds during use. A speed-test result alone cannot establish launch readiness.
- Security and reliability: Confirm ownership of security, load testing, and the systems behind forms, bookings, or orders.
- Privacy and legal wording: Ask the appropriate specialists to review tracking, consent, and policy content.
- Search and changed addresses: Assign indexing checks, old-to-new address mapping, redirects, and updated internal links to the technical team.
For changed addresses, point the team to Google Search Central’s site-move guidance. It covers migration work and reviewing restrictions used to keep development pages out of search.
Send Notes the Team Can Reproduce, Then Retest
Use the same note format for each problem, so the person fixing it can repeat your check. Include:
- Page address and browser.
- Real device or preview size, plus orientation.
- Steps followed, expected result, and actual result.
- Screenshot, where useful.
- Effect on the visitor’s task.
For example: “On the contact page, in the phone preview at 390 by 844 in portrait, I left the email field empty and pressed Send. The error appeared underneath the sticky footer, so I couldn’t read how to correct it.”
You can also structure a note as Given / When / Then, followed by the expected result:
“Given I’m on the contact page in the phone preview, when I leave the email field empty and press Send, then the error appears underneath the sticky footer. I expect to see the error beside the email field so I can correct it.”
Add the browser, orientation, and screenshot to that note. The developer should be able to repeat the problem and understand what it stops the customer from doing.
Add a coverage line to your recap: “Checked: [pages, sizes, browsers, and tasks]. Not tested: [outstanding checks and who owns them].”
Separate problems that stop a task from content corrections and visual preferences. Agree with the team which issues must be fixed before launch, who owns them, and what remains untested.
When a fix arrives, repeat the steps that exposed the problem and finish the affected task again. Send your review with its coverage and outstanding checks, so approval describes what you actually tested.
