A screenshot shows how a page looks, but does not prove someone can request a service through it. Give the review a task: find the relevant work, understand the offer and contact the team. Start at the address a customer actually lands on.
This guide covers the journey on a phone. Which fields to ask for and landing page structure are separate topics. We are not measuring speed, proving full accessibility or deciding a website needs a redesign because of one awkward section.
Choose a task and record the test conditions
Use a physical phone and open the website in a browser your customers use. Record the model, browser, URL, language and date. Try your usual connection, then another available network. This observes behaviour; it is not a laboratory speed measurement.
Ask someone who did not prepare the website to complete the task without hints. Do not tell them where the button is. Record where they stop and what they ask, not just elapsed time. If a real submission will affect the team’s work, agree a test contact beforehand and clearly label the message as a test.
| Entry point | Task | What to observe |
|---|---|---|
| Homepage | Find one specific service | Clear names and a route to the terms |
| Service page | Decide whether the offer fits | Scope, service area and next step |
| A link from a friend | Enquire with a task already in mind | Contact without visiting every page |
Read the terms on a small screen
Try reading the description, limitations and assessment process without constantly moving the page sideways. Increase text size using the browser’s available controls. Important content should not disappear behind a sticky panel or become a clipped line. Check tables and other complex content separately; they may have their own scrolling area.
Images and examples should provide context rather than hide terms in tiny lettering. Check FAQ expansion and closing any additional windows. Missing information is a content problem even when the layout technically fits.
Complete the enquiry with the keyboard open
Reach the enquiry and open the keyboard in the first field. Check that the field name, your text and instructions remain visible, and that you can move to the next field and submit button without accidentally closing the form. Try pasting an email address and available autofill: the site should not silently change your selection.
Check whether the field name still makes sense after you enter text. A hint inside an empty field alone is not a persistent label. Try a longer but relevant task description and a reply channel the person really uses. Do not enter sensitive information or someone else’s data just for a test.
Check an error and a retry
Leave a required field empty or enter an obviously invalid test address. Does the message explain what to fix? Can you find that field with the keyboard open? Correcting it should not require unnecessary retyping of the other information.
Test delivery failures in an agreed test environment; do not disable the live website’s services. A retry needs a clear explanation of the current state. If the connection drops and the result is unknown, first establish whether the enquiry arrived. Repeated tapping is not evidence that the form is reliable.
Confirm receipt, not just a message
After an agreed test submission, check both the understandable result on screen and receipt by the responsible person. Record where the enquiry arrived, whether it contains enough information to reply and whether the intended reply channel was retained. Browser success does not confirm inbox delivery.
If the main channel is a phone number or messaging app, open the link and check its number or profile. Do not start a call or conversation without agreeing it with the recipient. Switching to another app and making contact are different outcomes.
Log problems and decide what to fix first
- The URL and the point where the obstacle occurs.
- Phone, browser, language and test conditions.
- Expected action and actual outcome.
- A short note or screenshot without personal data.
- Whether it blocked an enquiry or only made reading harder.
- The person responsible for the fix and a repeat of the same scenario.
Start with obstacles that prevent finding contact details or completing an enquiry. Then address unclear terms, overlapping elements and input problems; separate decorative changes. If an issue occurs on several pages, give the developer the shared scenario rather than screenshots without context. After a change, repeat the original journey on the same phone.
To scope the work, use the redesign versus targeted fixes guide. After launch, keep a first-month observation plan.
Website support · Discuss fixes to your mobile enquiry journey
Mobile website testing FAQ
Is narrowing a desktop window enough?
It is a useful preliminary check, but does not reproduce a phone’s keyboard, touch input, browser or switching to another app. Check the important journey on a device.
Do I need to test every phone?
Agree the available devices and priority browsers, and record the sample. One successful phone does not prove compatibility with all of them.
Do I need to submit a real enquiry?
An agreed test with safe data can confirm receipt. Without one, clearly record that you tested only the interface or mocked delivery.
Does an awkward form mean I need a new website?
No. The cause may be a label, message or single section. First reproduce the issue and agree the scope of the fix.