The agency’s status update says the new landing page is “fully responsive.” A colleague asks whether that means it’s “mobile-friendly.” Both words sound reassuring, and many people use them interchangeably. Before you sign off on either promise, it helps to know the difference between responsive and mobile-friendly, starting with what each one actually covers.
The short answer is that they overlap but describe different things. “Responsive” describes how a layout behaves: one page that rearranges itself to fit the space it has. “Mobile-friendly” describes an outcome: a potential customer on a phone can read the page and complete what they came to do.
A page can be responsive and still be hard to use on a phone. A page can also work well on a phone without being responsive. So check both, and ask for both in your feedback.
Use Two Questions to Identify What Needs Work
Use these questions to separate layout problems from problems completing the main task, so your feedback names the change you need.
- Does the layout adapt? Text stays readable, images fit, and columns, menus, and buttons rearrange to fit the space without cutting anything off.
- Can a visitor complete the main task on a phone? Check whether they can find the main action and complete the steps that follow, including any menu or form.
Each combination of answers suggests a different request:
- Both work: move on to the wider launch checks and a check on real phones.
- The layout adapts, but the task is hard: ask for a usability change, such as moving the main action or simplifying the form. “Make it responsive” doesn’t describe the problem precisely enough.
- The phone task works, but the layout doesn’t adapt: ask how the phone experience is delivered, and ask to see it demonstrated at phone, tablet, and desktop widths. If the brief calls for responsive design, a usable phone version alone doesn’t meet that request.
- Neither works: name the blocked task and the section where it breaks, then ask for changes there first.
Compare the Layout and Try the Main Task
If the page already has an address, start by comparing its layouts and trying the main task yourself. Paste it into Online Website Previewer, which is free and needs no account, and press Preview. You see the live page at desktop 1920 by 1080, tablet 820 by 1180, and phone 390 by 844 side by side.
Each frame loads the real page, so a submitted form or an order is real. If the main task involves a form or checkout, agree on a safe test path with the team first. Then compare how each section rearranges across the three frames, and try the main task in the phone frame.
Use these three views for an initial comparison. For help choosing other widths to inspect, see which screen sizes to use when reviewing a website.
The phone preview shows how the page lays out at a narrow width in your current browser. The previewer doesn’t copy iOS, Safari, touch input, or device performance. For what still needs a real device, see what a phone preview shows and what to check on a real phone.
What “Responsive” Promises
MDN, Mozilla’s web documentation, describes responsive web design as an approach to make web pages render well on all screen sizes and resolutions while ensuring good usability. It is an approach, not a separate technology.
Google’s developer documentation describes a responsive site as one that serves the same page code at the same address on every device but displays the content differently based on the screen size.
For your review, that means a responsive promise covers the full range of sizes, not only the phone. It is a statement about how the layout will rearrange as the screen gets narrower or wider.
What “Mobile-Friendly” Promises
Google’s documentation lists three ways to provide a mobile-friendly experience: responsive design, serving different page code to different devices from the same address, and running a separate mobile site at its own address. The practical point is that “mobile-friendly” alone doesn’t tell you how the layout is built.
That is why the two words are not interchangeable in a brief. A team could meet a “mobile-friendly” request with a separate phone version that leaves tablets and desktops untouched. If you want one layout that works across every size, ask for responsive design and a usable mobile experience. Both requests belong in the brief.
If you want to know how a separate phone version differs from a responsive layout, the responsive vs adaptive guide covers that comparison.
How a Responsive Page Can Still Fail on a Phone
A responsive design rearranges content, but you still need to check whether the new order helps visitors complete the main task. Watch for these problems.
The page looks like a shrunken desktop page. Check this one on a real phone. If the text is tiny and you have to pinch to read it, report the page and section to the developer rather than guessing at the cause.
Something is wider than the screen. A wide image, table, or embedded video can push past the edge and make the whole page scroll sideways. Note which section it is.
The main action ends up out of reach. Suppose a booking page stacks neatly on a phone, but the “Book a table” button now sits below a long gallery. The layout adapted, yet a first-time visitor might never scroll that far. That is a usability problem, and the fix is about order and emphasis.
The menu hides the routes people need. A collapsed menu saves space, but check whether a potential customer can still find the pages they came for. The mobile menu guide covers that review in detail.
Ask the Team to Show You, Not Tell You
“It’s responsive” and “it’s mobile-friendly” are claims. Ask the team to demonstrate them instead. Useful requests sound like this:
- “Please show how the menu and the photo gallery rearrange between desktop and phone.”
- “Please walk me through booking a table on a phone, including the form.”
- “Please show the same page at a tablet size before we approve the layout.”
A badge from an automated test is not that demonstration. Google retired its Mobile-Friendly Test tool in December 2023, so a mention of it in an old report tells you little about the page you are reviewing today.
Write Feedback That Names the Gap
When something fails, say which of the two questions it fails. Naming the gap helps the team understand what went wrong, even though they will decide how to fix it.
Include the page and the size where you saw it, so the team can find the same view. A note might read: “Home page, phone preview at 390 by 844: the layout rearranges, but the ‘Book a table’ button sits below the gallery. Please show how a first-time visitor reaches it without scrolling past every photo.”
When the brief also says “mobile-first,” the mobile-first vs desktop-first guide explains what that adds. After checking the layout and the phone task, use the pre-launch checklist to continue the wider review.
