A phone preview can show the whole offer neatly arranged on your computer. But will a mobile visitor understand it, choose the right option, and take the next step? The useful question is how far the preview can help you judge that journey, and what you still need to try on a phone.
A good rule of thumb is to divide the review into two passes, keeping the action you want the visitor to take in mind:
- In the browser preview: Check whether the message, images, and route help the visitor understand the offer and find the next step.
- Directly in a real phone’s browser: Repeat those checks, then try touch, forms, and the space left by browser controls to see whether the visitor can continue.
A good-looking preview is a useful first pass, not proof that the phone experience works.
Before either pass, agree with your team on the review version, safe page address and route, permitted test details, and where to stop. A live preview contains the real page. Interactions can send information, create a booking, or take a payment, and stopping before Submit doesn’t make everything beforehand harmless.
You can begin by looking and reading while the test arrangements are being confirmed. Before following the interactive checks below, confirm which actions the agreed route allows, including menus and fields. Complete a submission only when it is explicitly part of that agreement.
If you need an initial review before a meeting, start with the message, important image details, and route to the next step.
Repeat those checks directly on an available phone, adding touch and any forms the journey depends on when safe testing is agreed. Record the remaining checks as outstanding, rather than treating this shorter pass as a completed phone review. The recap format at the end helps you separate that initial pass from the followup work.
What to Check in the Browser Preview
Online Website Previewer is free and needs no account. It shows the interactive live page, not screenshots, in phone, tablet, and desktop layouts. Paste the agreed page address and press Preview, then compare the phone layout with the desktop and tablet layouts. Read through the relevant content in each view to see what moves, disappears, or becomes harder to understand.
The page still runs in your computer’s browser, so a phone-shaped view doesn’t turn it into a phone browser.
Follow the Page’s Purpose Through the Visitor’s Eyes
Start with what the visitor came to do and the specific action this page should help them take. Step into that person’s shoes and review the mobile layout from their arrival through the decision to continue. Can they understand the offer, find what they need to decide, and recognize the next step?
For someone comparing service plans before requesting a demo, look for the plan differences, relevant limits, and a clear way to request that demo. The button alone isn’t the goal: the visitor needs enough information to choose a suitable plan before making contact.
Scroll through the relevant page with that journey in mind. Read the headings, labels, and explanations that support the decision, looking for cut-off wording, overlapping sections, or information that appears only after the choice it should explain.
If the route breaks down, name what the visitor needs at that point. Ask the team to keep the message readable, put decision-making information before the related action, and make that action clear. This checks the visible journey, not the reading order used by a screen reader.
Check What the Images Still Explain
Compare important photos, diagrams, and banners in the narrow and wide views. Can you still see the product detail or explanatory label? Has the image stretched, or has an important part become too small to understand?
Shrinking a desktop image can preserve its shape while losing its purpose. A wide photo might leave the product tiny on a phone, or its crop might remove the feature the nearby text describes.
Show the designer which detail needs to stay visible. Where the desktop composition fails in the phone layout, ask for a different phone crop or composition, with dimensions suited to that placement. A wider desktop image and a more closely framed phone version may communicate better than the same composition squeezed into both.
That doesn’t mean every phone image needs to be portrait or that every page needs two image files. If the existing image explains the offer in both layouts, keep it. The visual example of when a different image crop helps on a smaller screen can help you discuss the result with your designer without choosing the code.
Follow the Route to the Next Step
Within the safe route you agreed on, open the menu, read its choices, and follow the next step. Does the label make the intended action clear, and does the destination let the visitor continue toward it?
For a service-plan page, finding a plan should lead to the right details or agreed inquiry route. A menu that opens successfully can still leave the customer unsure which choice to make.
Record the label you selected and the heading or state that appeared. Ask for a clear route and a destination that matches the promise. If something behaves differently inside the preview, compare it with the page opened directly before calling it a customer-facing defect. Embedded pages can encounter different permissions and cookie rules, so let the team investigate the cause.
What to Check Directly on a Real Phone
Ask whoever owns the visitor data which phone and browser combinations matter for this page’s audience. Include iPhone and Android combinations where those audiences matter. If you don’t have that information yet, begin with an available phone and name it in your notes. Say that the audience’s other phone/browser combinations still need an agreed review, rather than waiting to start or claiming that your phone represents everyone.
Open the agreed page address directly in each selected phone’s browser, not inside the previewer. One phone covers that particular setup, not every phone your customers use.
Repeat the Visible Checks
Read the page again, compare the important image details, and follow the approved route. Check both orientations where the task permits rotation. Do this even when the preview looked good.
Checking on a real device brings together its browser, operating system, screen size, and the space its controls leave for the page. Your computer’s preview cannot establish how all of those behave together.
If the phone reveals a problem, record the page, phone, browser, orientation, and steps that exposed it. Ask the team to keep the message readable and the route usable in that setup. For an image, check whether the chosen crop still helps at its actual displayed size.
Try Nearby Links and Menu Choices with a Finger
Use your normal comfortable grip to select important choices. Notice repeated taps, opening the wrong nearby link, or a close control you can see but struggle to reach. Check that the route doesn’t depend on moving a mouse over something.
A mouse can select a choice that a finger struggles to separate from its neighbor. Nielsen Norman Group’s examples explain why touch targets need room around them.
Name the choices involved and ask the team to make them independently tappable. They can assess size, spacing, and access. One successful tap doesn’t establish that the controls work for everyone, and you don’t need to diagnose their implementation to report difficulty.
Try the Keyboard and Form Fields
If the journey uses a form, focus the fields the customer needs on the approved test route and enter permitted details. Can you enter the required characters, see the active field and its label, correct a mistake, and reach the next step? If an approved test profile already has harmless autofill details, inspect where those details go.
Phone keyboards and form controls vary. Autofill also depends on saved browser information, so a missing suggestion alone doesn’t prove that the form is wrong.
Record a field that’s hidden while typing, required punctuation that’s hard to enter, or details filled into the wrong place. Ask the team for a form that accepts valid information and keeps the current field, correction, and next action visible. Include whether the keyboard was open when the problem occurred.
The examples of what to check when a phone keyboard opens can help you recognize those problems. Follow your agreed route, test details, and stopping point rather than the linked page’s general submission advice. Only complete a submission if your team has explicitly included it in the safe test.
Scroll with Browser Controls and Sticky Bars Visible
Move down the page and back up. Where the browser hides and reveals its address or tab bars, compare both states. Recheck any header that stays on screen, bottom action, or open panel, and note keyboard-open problems separately.
Those browser controls change how much of the page is visible. A header or bottom bar that seems unobtrusive in the preview can cover the explanation or action someone needs on the phone.
Record what covers what, the orientation, scroll direction, and whether the browser bars or keyboard were showing. Ask the team to keep essential text, actions, and panel-close controls visible and reachable in those states. Describe the obstruction rather than guessing at a browser bug or prescribing a code change.
Check Enlargement Separately
On the directly opened page, use the phone browser’s supported enlargement or text settings. Record which method and setting you used, then try reading and reaching the same content again.
A closer view in the previewer is not a phone text-enlargement test. Pinching to magnify the phone page and changing its text size can also produce different results, so keep those observations separate.
Report clipped words, hidden controls, or content you cannot reach, along with the setting that exposed them. Ask the person responsible for accessibility to assess the problem and the wider requirements. If nobody has that role, ask your developer or agency who can cover it. W3C explains why enlarged text must keep its content and controls usable.
Having to pan sideways while pinch-zoomed is not, by itself, proof of an accessibility failure. This spot check also doesn’t establish screen-reader access, contrast, or overall accessibility.
Notice Waiting and Movement, Then Ask for Measurement
Watch the page appear and respond during the approved journey. Note delayed feedback, content that jumps and moves the next action, or a route that stalls. Record whether this visit used Wi-Fi or cellular.
These are useful symptoms, not a performance score. One phone visit can differ from another because of the device, connection, saved content, and what the visitor does. A fast laptop preview cannot settle the loading experience on mobile.
Send the symptom, environment, and steps to your developer or agency, or whoever handles performance for the site. Ask them to investigate stable content placement and prompt feedback with repeatable tests and relevant real-user data. You don’t need to identify the cause or promise a speed threshold.
Send Findings with Their Coverage
Keep the customer’s goal beside your notes. For a campaign page, follow its focused promise through the safe route. For a redesign, cover the important journeys you agreed on rather than treating every page as one conversion funnel.
Keep each finding as short as the problem allows: where you were, what you did or saw, and why it matters. Add the page version, phone/browser, orientation, or steps when they help someone find and repeat the issue. Include a screenshot when useful, keeping private information out.
An illustrative note might read: “On [phone and browser], after I scroll back up the plan page, the bottom bar covers the plan limits. Those limits need to be readable before I choose a plan. Please check that state with the browser controls showing.”
Finish with what you checked, where you stopped, and what remains with someone else. A test confirmation doesn’t prove that an inquiry reached the right person, and one phone doesn’t establish every visitor’s experience. Name the outstanding device coverage, delivery checks, performance measurement, and accessibility assessment so your team knows what to do next.
A short recap can use this format: “Checked [page/version] in [preview layouts] and directly on [phone/browser]. Found [main issues]. Stopped at [agreed boundary]. Still to check: [remaining environments or tasks, and who will cover them].”
For help turning your observations into clear requests, read our guide on how to give useful feedback on a website design.
