A mobile audit does not need to begin with a long technical report. Begin with a customer task and a real phone. Try to find a service, understand the offer and contact the business without asking a colleague what to do. Every hesitation is a useful observation. The purpose is to identify friction you can describe and reproduce.
Choose tasks that reflect real intent
Pick three tasks from recent enquiries. A visitor might need a starting scope, directions to a venue or confirmation that a service suits their business. Write each task in ordinary language and give it to someone who did not design the website. Watch without coaching. Note where they scroll back, misread a label or leave the page.
Use your priority pages rather than only the homepage. Search visitors often arrive directly on a service or article. Check that those pages explain the business and offer a sensible next step on their own. A polished opening screen is not enough if the page that answers the customer's question is difficult to use.
Read the page in ordinary conditions
Review body text, captions, prices and form instructions with normal phone settings. Can a reader distinguish headings from decoration? Does the most important explanation appear before a long sequence of imagery? Are buttons descriptive enough to predict the destination? Write specific notes, such as a covered submit button, rather than a vague statement that the page feels crowded.
Try portrait and landscape orientation, a narrow screen and text enlargement. Open the navigation and close it again. Check that sticky controls do not hide the page or block the final form fields. Motion should support understanding rather than make the page harder to read. A quiet static state is worth testing alongside the animated one.
Test the form through failure and success
The W3C forms tutorial recommends clear labels, useful instructions and feedback that helps people correct mistakes. Inspect the actual journey: leave a required field empty, enter a plausible international telephone number, correct an error and submit. Arrange any live submission test with the receiving team and label the message clearly.
Check what the user sees afterwards. A form should not imply that a booking is confirmed when it merely sends a request. If the action opens a separate app, explain what remains for the visitor to do. Keep information already entered when a recoverable error occurs, where the workflow permits it.
A worked example: rank problems by task impact
Imagine an illustrative audit with ten observations. Four are minor spacing issues, three are unclear labels, two make a key paragraph difficult to read and one prevents submission on a small screen. Assign a simple internal priority: blocks the task, causes repeated confusion, or cosmetic. Fix the blocked submission first even though it represents only one of ten findings.
For a basic task-completion measure, ask five reviewers to complete the same task. If three finish without assistance, the observed completion rate is three divided by five, or 60 percent. This is a tiny usability sample, not a market estimate. Its value is in revealing specific failures to investigate and retest, not producing a dramatic headline.
Your mobile review checklist
- Test the top three customer tasks from direct-entry pages.
- Read final text at common phone widths and enlarged text settings.
- Open and close navigation without losing your place.
- Check links, telephone actions and external-app handovers.
- Complete forms with both valid and missing information.
- Verify that errors explain the correction required.
- Confirm the final message matches the actual business action.
- Record device, browser, page, steps and expected outcome.
Turn observations into a useful repair brief
Give each issue a short description, screenshot where appropriate, reproduction steps and customer impact. Assign an owner and a retest date. A developer can act on “the keyboard hides the final input on this screen” more easily than “make mobile better.” Keep the original test task so you can verify that the change solves the problem.
A frequent mistake is treating an app as the automatic answer to website friction. Sometimes a simpler page or clearer form is enough. A dedicated app has its own audience, distribution and maintenance needs. Decide based on repeat use and required capabilities rather than frustration with one poorly arranged screen.
YAMAR offers responsive websites and scoped mobile app work. Bring your task list and audit notes to the mobile experience discussion. We can assess whether the first useful step is a website repair, a progressive web app or a dedicated app, then document what belongs in that release.