RytellStart with a real customer task
Open your homepage on a phone you use. Turn off Wi-Fi for one pass if you have mobile data available. Visit a service page and the contact page, then repeat the task on another browser or device when possible. Browser emulation helps check widths, but it does not replace testing the keyboard, dialing behavior, or touch interaction on a phone.
For a Phoenix junk-removal business, the task might be finding out whether the company serves your ZIP code and accepts a bulky item. For an HVAC business, it might be finding repair availability and a working contact method. Use the services your company actually offers.
Check the first screen and navigation
- Can you tell what the business does and where it works?
- Does the main button describe its destination, such as “Request a Quote”?
- Can you open the menu, reach services and contact information, and close it again?
- Does an open menu leave the close control visible? Can a keyboard user dismiss it?
- Do chat widgets, cookie notices, and sticky buttons leave room to read and act?
Record the exact page and problem. “The menu covers the quote button at this width” gives a designer more useful information than “mobile feels off.”
Make text and controls comfortable to use
Read a full paragraph without pinching the screen. Increase text size using your device's accessibility settings and check that the page still works. Watch for clipped headings, prices outside their containers, and horizontal scrolling. Keep important service details available on mobile; Google uses mobile content for indexing.
For primary buttons, aim for at least 44 by 44 CSS pixels and leave space between nearby controls. That is a practical design target. WCAG 2.2's Level AA minimum target-size criterion uses 24 by 24 CSS pixels, with specific exceptions and spacing provisions. See W3C's explanation of target size. A comfortable button alone does not establish accessibility compliance.
Follow the page with a keyboard as well. The focused link or button should be visible. Read our website accessibility guide for a broader review.
Test the whole inquiry path
- Tap the phone link and check the displayed number before placing a call.
- Open the form. Check that each field has a visible label and that the phone and email fields offer useful keyboards.
- Try submitting with a required field empty. The error should explain what to fix without erasing the other entries.
- Send one clearly labeled test submission. Confirm the receiving inbox or customer system gets it.
- Open the booking link and check the service, time zone, and available appointment types. Coordinate any test booking with staff, then remove it.
Keep link clicks separate from completed calls, delivered forms, and confirmed bookings. Our lead-tracking guide explains how to record those outcomes.
Use speed reports to find specific repairs
Run the pages through PageSpeed Insights and select the mobile report. Lab results come from a simulated test; field results, when available, describe real-user experiences over a collection period. A small or new site may lack enough field data. Check whether the report describes the page or the whole origin. Google explains the difference between lab and field data.
Look for a large opening image, delayed content, or layout shifts that move a button while someone taps it. Ask for the underlying repair and a repeat test under comparable conditions. A better lab score does not guarantee a search position. Our guide to slow business websites covers common causes.
Download and work through the checklist
Download the mobile checklist (CSV)
The checklist includes space for the page, device, result, repair owner, and retest date. Open it in a spreadsheet, wrap the text, and print it in landscape orientation if you prefer a paper copy. Use “not tested” until you have tried the action.
Record three kinds of work: a broken customer action to repair first, a reading or navigation problem to improve next, and a cosmetic preference to discuss later. Retest the same task after each repair.
Decide whether to repair or rebuild
A few oversized images or cramped buttons usually justify a targeted repair. Repeated problems across the menu, page templates, and forms may justify a broader project. List the affected pages and ask for a scoped estimate before choosing a rebuild.
Use our redesign versus refresh guide to compare the options. RDS offers small business web design and Phoenix web design with the contact path included in the review.