How to run a mobile website task test without design software

You can run a useful mobile website task test with a real phone, a short task list and a note sheet. You do not need design software to notice unreadable text, blocked controls or a form that loses information. Keep the device and tasks consistent so findings describe user difficulty rather than personal taste.

Choose tasks and conditions

Pick three to five journeys that matter to the site's audience, such as finding a service, checking opening hours and reaching an enquiry form. Use an ordinary phone and record its screen size, browser and connection. If you can, repeat on another device or ask another person to try. A single phone is a starting point, not proof that every mobile visitor has the same experience.

Start each task from the page a visitor would plausibly enter, not always the homepage. Search visitors often land directly on a service page.

Observe interaction, not screenshots alone

Try the menu, links, text fields and any sticky buttons. Does a fixed banner cover a control? Can you read the text without zooming? Does the page jump when a form error appears? Note the step where the task becomes uncertain. A screenshot can document what was visible, but a short recording or written sequence captures the interaction.

If a button is difficult to use, note whether its label, size, spacing or position caused the problem. The remedy depends on the cause.

Assign severity with a reason

Use a simple scale: blocked task, significant delay, minor friction or observation only. Give each issue a user task and a device. “Contact button hidden beneath the cookie banner on this phone” is more useful than “mobile design is poor”. Avoid assuming that every visitor will be affected until you test more devices.

A mobile website design review provides additional patterns to inspect after the task test.

Retest one change

After a fix, repeat the same task on the same device and then on another phone if available. Check that the correction did not create a new problem elsewhere. Keep both the original observation and the retest result so the team can see what improved.

Example: a sticky button that hides the answer

Imagine a visitor opens a pricing page and a fixed “Get a quote” bar covers the sentence explaining what the price includes. The bar may be helpful on another page, but here it blocks the decision the visitor needs to make. Record the phone model, browser, page, scroll position and whether the bar can be dismissed. Ask a second person to try the same task. A useful recommendation is to restore access to the information and retest, not simply to remove every sticky control from the site.

Frequently asked questions

Is a phone simulator enough?

It can help, but a real phone reveals touch, keyboard and connection behaviour that a desktop preview may miss. Test at least one common device with its normal browser and on-screen keyboard.

How many people should test?

Start with a small number of relevant users for an early review. Add more when the journey is important or findings conflict.

Should every mobile issue be fixed before launch?

Prioritise blocked and high-impact tasks first. Record remaining issues with owners and dates rather than forgetting them. Recheck the highest-risk journeys after each correction, especially contact and payment steps.