guides 11 min read

Mobile Website Feedback From Clients: How to Collect It Without Guessing Which Phone They Use

The fastest way to collect useful mobile website feedback from a client is to stop asking "how does it look on your phone?" and instead give them a link they can open on that phone, tap on the exact element that bothers them, and leave a comment that automatically carries the device, browser and screen size with it. No screenshots, no WhatsApp voice notes, no guessing which phone they meant.

Contents

The problem: "It looks weird on my phone"

You know the message. It arrives on a Sunday evening, from a client who is lying on the couch with their iPhone: "Hey, the website looks weird on my phone. Can you fix?"

That is the entire bug report. Now you have to play detective:

  • Which phone? An iPhone 12 or a 15 Pro Max? An old Samsung with a cracked screen?
  • Which browser? Safari, Chrome, the in-app browser inside Instagram?
  • Which page? The homepage, or the contact page they opened by accident?
  • What exactly looks weird? The menu, the hero image, the font size, the button that "feels too small"?
  • Portrait or landscape? Dark mode or light mode? Text size increased in accessibility settings?

You reply with a polite wall of questions. The client answers two of the five. Three days later you get a cropped screenshot, taken with the keyboard open, of a page you cannot identify. You open Chrome DevTools, pick iPhone 14 from the dropdown, and everything looks fine. You tell the client it looks fine on your end. The client says "no, it's definitely broken." Nobody is happy.

This is not the client's fault. Most people have never heard of a viewport, and they have no reason to. They see a rendered page on a small screen and they react to it the way a visitor would. That reaction is valuable. The problem is that the usual feedback channels (email, WhatsApp, a shared Google Doc) strip away every piece of context you need to act on it.

Here is what typically goes wrong with mobile feedback specifically:

  • The screenshot has no metadata. A PNG from a phone does not tell you the browser, the OS version or the viewport width.
  • Desktop feedback and mobile feedback get mixed up. One email contains six points, and you cannot tell which ones apply to which screen size.
  • The client reviews on a device you do not own. Their five-year-old Android phone renders things differently from your testing setup, and you cannot reproduce it.
  • Feedback arrives in fragments. A message at 8:12, another at 11:40, a voice note the next morning. By the time you sit down to work, you are stitching together a puzzle.
  • Clients review on mobile last, if at all. Many only look at the desktop version in the meeting, then open the link on their phone a week later, right before launch. That is when the surprises show up.

Mobile traffic is now the majority of web traffic for most small business sites, so this is not an edge case. For a restaurant, a hairdresser, a local trades business, the phone version is the website. It deserves a proper feedback process.

The 7-step process for collecting mobile feedback

Use this as a repeatable checklist for every project. It works on any platform, whether you build in Webflow, Framer, WordPress, Shopify or custom code.

  1. Test the mobile version yourself first, on at least two real devices
  2. Tell the client up front that mobile review is a separate round
  3. Send one review link that works on any device, with no login
  4. Ask the client to open it on their own phone, not a desktop browser window resized small
  5. Give them three specific things to check, not "have a look"
  6. Collect every comment as a pin on the page, with device data attached
  7. Triage by viewport, fix in batches, and resolve each comment visibly

Each step is small. The point is that together they turn "looks weird on my phone" into a ticket you can actually work through. Let's go through the parts that matter most.

Step 1 and 2: Do your own pass, then set expectations

Before the client ever sees the mobile version, check it yourself. DevTools device emulation is a good start, but it is an approximation. Emulators do not reproduce Safari's address bar that collapses as you scroll, the 100vh bug, iOS form zoom on inputs under 16px, or the way a real thumb interacts with a sticky header.

A realistic minimum before sending a link:

  • One iPhone (Safari) and one Android phone (Chrome), real devices if you have them
  • A narrow viewport around 360px wide, because that is where layouts usually break first
  • A tablet or landscape check, since "it looks fine on my phone" often becomes "it looks weird on my iPad"
  • Tap targets, form inputs, menu open and close, and any sticky or fixed elements

If you do not own multiple devices, ask a friend to open the link, or use a cloud device service for the final check. You will not catch everything, and that is fine. The goal is to remove the obvious problems so the client's time is spent on things only they can judge: tone, priorities, whether the important button is the one that stands out.

Then set expectations. A short sentence in your kickoff email or project brief does the job:

"Design review happens in two rounds: desktop first, then mobile. For the mobile round, I'll send a link you open on your own phone."

This one line prevents the classic situation where the client approves the desktop design, you finish the build, and then they discover on launch day that the mobile menu is not what they imagined. It also makes the mobile round countable, which matters when you track revisions (more on that in our guide to the web design revision process).

The biggest unforced error in mobile review is asking clients to "make the browser window smaller." Do not do this. Non-technical clients do not know how to resize a window, and a narrow desktop window is not a phone: touch behavior, browser chrome and font rendering all differ.

Instead, send a single review link and tell them to open it on their phone. A link is easy to send by email, message or QR code, and it makes the whole thing feel like using the site, which is exactly what you want.

The link must work without friction. If your feedback tool asks the client to create an account, verify an email address and remember a password, you will lose a big share of them at the signup screen, especially on a phone, where typing is already annoying. That is why no-login feedback matters so much for mobile. We wrote more about this in website feedback tool with no login.

A few practical tips for the handover:

  • Send the link by the channel the client already reads on their phone. For many, that is WhatsApp or a text message, not email.
  • Add a line like "Open this on your phone, in your usual browser" so they do not open it in a desktop tab by habit.
  • If the review environment needs a passcode, include it in the same message so they do not have to hunt for it.
  • Keep the staging site stable while they review. If you push changes mid-review, comments pinned to old elements become confusing. See staging site best practices for how to set this up.

Step 5: Give three specific things to check

"Have a look and let me know what you think" produces vague feedback on any device. On mobile it is worse, because the screen is small and clients tend to scroll quickly, say "looks fine," and move on.

Give them a short, concrete task list instead:

  1. Open the menu and visit three pages. Can you find what you were looking for?
  2. Find the main call to action on the homepage. Is it clear what to tap?
  3. Try the contact form or the booking button. Does it work and feel comfortable?

Three prompts like this turn a passive glance into a small usability test. You also get feedback on what matters to the business, not just on aesthetics. If a client reports "the phone number is hard to find," that is worth more than ten comments about font weight.

Add one more invitation: "If anything feels off, tap on it and write what you see." That sentence tells them what to do with the problem, which is half the battle.

Step 6: Pin the comment to the element, with the device data attached

This is where the process either works or falls apart. A comment on mobile needs three things attached to it:

  • Where: the exact element or position on the page the client is talking about
  • What: their own words, in plain language
  • On what: device, operating system, browser and viewport size

Without the third part, you are guessing. With it, you can reproduce the issue in minutes.

This is what dotts does. The client opens the shared link on their phone, taps anywhere on the page, and types a comment. The pin sits on that spot. dotts captures the browser and device information automatically, so you do not have to ask "which phone is that?" You see it next to the comment.

Compare the two versions of the same feedback:

Before: "Menu looks weird."

After: a pin on the hamburger icon, the comment "Menu overlaps the logo when I open it," and the device note: iPhone, Safari, 390px wide.

The second one takes thirty seconds to fix. The first one can take an afternoon of back and forth.

dotts also supports file attachments, @mentions and emoji reactions. On mobile, the reactions are surprisingly useful: a thumbs up on a section you changed is faster than typing "looks good now." And it works on websites, PDFs and images (JPG, PNG, SVG, HEIC), so if you are sending a mobile mockup as an image before the build, the client can pin comments on that too.

If you want to compare how other tools handle this, our roundup of the best visual feedback tools for freelancers covers the differences in login requirements and pricing.

Step 7: Triage by viewport and fix in batches

Once the comments are in, resist the urge to fix them one by one in the order they arrived. You will waste time context-switching and you will break things in the process.

Sort them into groups instead:

  • Layout bugs: overlapping elements, overflow, broken grids. Fix these first, because they often cause several other comments.
  • Readability: font sizes, contrast, line length, spacing between tap targets.
  • Content priorities: "I want the phone number higher," "the second section is not important on mobile." These are decisions, not bugs.
  • Device-specific oddities: something that only breaks on one OS or browser version.

Fix each group in a single session, test on real devices again, and then mark the comments as resolved. The client sees the status change and knows you have acted on their feedback, which cuts down on "did you get my message?" follow-ups.

One caution on content priorities. Mobile feedback is where scope creep loves to hide. "Can we reorder everything on mobile?" is a design change, not a bug fix. Decide in advance whether your package includes custom mobile layouts per section or just a responsive version of the desktop design. Our article on scope creep in web design goes into how to draw that line.

Common mobile feedback problems and how to read them

Some client phrases come up again and again. Here is a quick translation guide.

"The text is too small." Usually body text under 16px, light gray on white, or a font with a small x-height. Check contrast and size before you argue about taste.

"The button doesn't work." Often a tap target under 44px, an element covered by an invisible overlay, or a sticky bar that blocks the click. Rarely a real JavaScript failure.

"The page jumps when I scroll." Typically the mobile browser address bar collapsing and changing the viewport height, combined with a full-height hero using 100vh. Use dynamic viewport units or a fixed fallback.

"It looks different from the design." Sometimes true, sometimes the client is comparing the live site to a desktop mockup because you never showed a mobile design. This is another reason to include mobile in the design round, not only in the build.

Real-world example: Mara and the bakery site

Mara is a freelance web designer in Hamburg. She was building a site for a family bakery, and the owner, Heike, reviewed everything on her phone because that is how she runs her business: orders, messages, and supplier calls, all from one phone.

The first round went the way many do. Mara sent a staging link by email. Heike replied two days later: "On the phone the page is a bit strange, the pictures are cut off and I can't find the opening hours." Mara tested on her own iPhone and saw nothing wrong. She asked which phone Heike used. No answer for a day. Then a WhatsApp screenshot arrived, taken in landscape mode with the keyboard half open. Mara spent 90 minutes guessing and rewrote the hero section twice. Heike still was not satisfied.

For the second project phase she changed the process. She sent a dotts link via WhatsApp with the message: "Please open this on your phone and try three things: find the opening hours, tap the order button, and look at the cake photos." Heike tapped on the hero image and wrote, "Cake is cut in half." She tapped the footer and wrote, "Hours too small, I can't read them." dotts showed Mara the device and browser data: an older Android phone with a narrow viewport and Chrome. Mara reproduced the issue in ten minutes: the hero image used a fixed focal point that cropped badly at that width, and the footer text was 12px.

She fixed both, replied to the comments, and marked them resolved. Heike gave the thumbs-up reaction on both. Total time for that round: about 40 minutes, compared with roughly four hours in the first round, including the email back-and-forth. The mobile approval also came before launch week rather than during it.

Bottom line

Mobile feedback goes wrong because the context disappears, not because clients are unclear. Give them a link they can open on their own phone, tell them what to check, and use a tool that records where they tapped and what device they were on. You will fix the right things faster, and the mobile round stops being the one that delays your launch.

FAQ

How do I get mobile website feedback from a client who isn't technical?

Send a single review link and ask them to open it on their own phone. Give them two or three simple tasks, like finding the opening hours or tapping the main button. A tool where they can tap directly on the page and type a comment, without creating an account, removes most of the friction.

What information do I need to reproduce a mobile bug?

At minimum: the device or operating system, the browser, the viewport width, and the exact page and element involved. Asking clients for this manually rarely works. Use a feedback tool that captures browser and device data automatically, as dotts does with every comment.

Is Chrome DevTools device mode enough for testing mobile websites?

It is a good first check, but not a replacement for real devices. Emulation does not reproduce real touch behavior, the iOS Safari address bar, font rendering differences or performance on slower phones. Test on at least one real iPhone and one real Android phone before the client review.

Should mobile feedback be a separate review round?

Yes, in most projects. Separating desktop and mobile rounds keeps feedback organized and makes revisions easier to count. Mention it in your kickoff so the client expects it. It also prevents desktop approval from being mistaken for approval of the whole site.

How can clients leave feedback on a website from their phone without logging in?

With a no-login feedback link. The client opens the URL, taps anywhere on the page, and leaves a pinned comment. dotts works this way, so there is no signup step on a small screen. You can protect the link with a passcode if the staging site should not be public.

What if a client's phone shows something I can't reproduce?

Check the device and browser data attached to the comment, then match it as closely as possible: same viewport width, same browser, and if you can, a real device or a cloud testing service. Also check for accessibility settings like increased text size, which can change a layout significantly.

How many mobile revision rounds should I include?

Many freelancers include one or two rounds for responsive adjustments, and treat custom mobile layouts per section as a separate scope. Whatever you choose, write it down in your contract and brief, and count each round clearly.

Can I collect mobile feedback on designs before the site is built?

Yes. Export your mobile mockups as images or a PDF and share them for pinned comments. dotts supports JPG, PNG, SVG and HEIC images and PDFs, so clients can comment on the mobile design before you spend hours building it.

Stop guessing which phone your client is using. Try dotts free →

Further reading

Leon Eikmeier

Leon Eikmeier is co-founder of dotts and has been building websites for freelancers and agencies for over 8 years.

Start Collecting Feedback in Seconds with dotts

Forget messy email threads and unclear revision requests. dotts makes feedback fast, clear, and organized so you can focus on what matters—getting work done.

Try it for Free