Audit the mobile site by trying to finish real tasks on a phone, not by shrinking a desktop browser and admiring the layout. A useful test asks whether a visitor can read a service answer, find the right location or provider, tap the intended control, submit a form, place a call, recover from an error, and understand what happens next.
Use at least one ordinary phone, mobile data as well as Wi-Fi, and the live pages people actually enter from search or ads. Record a reproducible defect for every failure. “Mobile feels cluttered” is not a repair ticket. “The keyboard covers the form error and the page does not move focus to it” is.
Choose three journeys before testing components
Pick journeys that represent different kinds of intent. A reasonable starting set is:
- confirm that a named service is available at a specific location;
- find a suitable provider and reach the booking option;
- contact the practice after hours and understand the response expectation.
Write the starting URL and finish condition for each journey. If the first journey succeeds only when the tester already knows the internal name of the department, it has not really succeeded.
Avoid beginning from the homepage every time. Many mobile visitors land on a service, provider, location, or campaign page. Start from those entry points so the test includes the first decision they actually encounter.
Before the test, turn off any developer login, saved form autofill, or office-only network shortcut that a public visitor would not have. Use approved test details, never real patient information.
Check whether the page can be read without repair work from the visitor
Hold the phone at a normal distance and read the first screen. The service, audience, location context, and next useful action should not require pinching, horizontal scrolling, or dismissing several overlays.
The World Wide Web Consortium’s reflow guidance uses a 320 CSS-pixel width as an important small-screen reference and expects content to reflow without two-dimensional scrolling, apart from content that genuinely needs it. Test at narrow width and at 200 percent zoom. Look for clipped headings, overlapping controls, tables that force the whole page sideways, and sticky elements that consume most of the screen.
Readability is more than font size. Check:
- line length and spacing in dense paragraphs;
- contrast in normal, visited, error, disabled, and placeholder states;
- headings that explain the section rather than decorate it;
- abbreviations and medical terms that are defined where needed;
- critical qualifications that do not disappear below a visual;
- phone numbers, hours, locations, and next steps written as text.
Ask the tester to explain the page’s answer in one sentence. If the words are technically visible but the answer remains unclear, the defect is content, not only design.
Test every tap at the moment it appears
Use a thumb and tap links near other controls. Watch for missed taps, accidental taps, moving buttons, invisible focus, and controls hidden behind consent banners or sticky navigation.
WCAG 2.2’s Target Size Minimum criterion sets a 24 by 24 CSS-pixel minimum or sufficient spacing through defined exceptions. Treat that as an accessibility baseline, then test whether the control is comfortably usable in the real layout. A technically qualifying icon can still be confusing if its purpose is not named.
Pay special attention to:
- menu buttons and close controls;
- provider and location cards;
- phone, directions, and booking actions;
- date pickers and dropdowns;
- consent choices;
- inline links at the end of long paragraphs.
Rotate the phone once. A page does not need a special landscape design, but orientation should not trap the visitor or hide the action they were using.
Complete the form rather than inspecting it
Fill every public form from start to confirmation. W3C’s forms guidance recommends visible labels and clear instructions, and it stresses telling people what went wrong and how to correct it. Placeholder text alone is not a reliable label because it disappears during entry.
First submit with all fields empty. Then create one error at a time: omit a required field, type an invalid email, use a short phone number, and choose no required option. Confirm that the error:
- appears beside or clearly identifies the affected field;
- uses plain words;
- remains visible above the mobile keyboard;
- moves focus or provides an obvious route to the problem;
- preserves correct entries when the visitor fixes it.
Next submit approved test data. Check the loading state, duplicate-tap protection, success message, email or system receipt if applicable, and the operating team’s receipt. A confirmation that says only “Success” leaves the patient guessing. It should explain whether the request was received, what kind of response to expect, and what to do if the need is urgent or the response does not arrive.
Only ask for fields necessary to handle the stated request. A longer form creates more mobile work and more information to govern. Field minimization decisions should be made with the practice’s privacy and operating owners.
Call the number and inspect the handoff
Tap every public phone number. Confirm that the dialer opens with the correct number, including any extension logic. Compare the displayed number with the destination used by call tracking. Test the sticky call control separately from numbers inside the page.
Do not judge success by the dialer alone. Use an approved test call to confirm routing, after-hours behavior, queue announcements, voicemail, and any location-specific path. Listen for a mismatch between the page promise and phone reality, such as a “24/7” action that reaches an unmonitored mailbox.
If the site offers text messaging, patient portal access, or an external scheduler, test those as separate handoffs. Record the destination domain and the point where the visual and navigation context changes. The visitor should know they are leaving the practice site and what task they can finish next.
Give each defect a repair-ready record
A useful mobile bug report includes the journey, URL, phone and browser, network, timestamp, steps, expected result, observed result, screenshot or short recording, and severity. Redact test details from evidence before sharing it.
Use severity based on task consequence:
Severity • Mobile finding • Expected response
- Blocker | Booking, form, or call cannot be completed | Repair before promoting the path
- High | Key answer is hidden, wrong, or extremely hard to reach | Prioritize in the current release
- Medium | Task succeeds with avoidable confusion or repeated effort | Schedule a bounded fix
- Low | Cosmetic issue with no meaningful task effect | Bundle with related work
The same defect on a shared template may affect dozens of URLs. Link it to the component or template rather than opening a separate ticket for every page.
Run a focused 45-minute review
This timing is a practical starting point, not a standard. Spend 10 minutes on the three entry journeys, 10 on reading and zoom, 10 on forms and errors, 5 on calls and external handoffs, and 10 documenting the most consequential findings. Stop if you discover a serious privacy or safety issue and escalate it rather than recording sensitive evidence.
Repeat the review after repair using the same devices and finish conditions. Then add one unfamiliar tester who did not help build the site. Familiarity lets staff mentally fill in missing labels and expected next steps.
The goal of healthcare website design is not a phone-sized desktop page. It is a journey that remains understandable and operable under the conditions people actually use. Start with one service-to-booking path, complete it with one thumb, and turn every point of friction into a defect someone can reproduce.