Create a Marketing Campaign Mobile Form Usability Test Script

Overview

A repeatable test script for checking whether people can complete campaign forms on mobile devices, understand each field, recover from errors, and know what happens after submission.

Set the task and test conditions

Choose a realistic task, such as requesting a quote, registering for an event, booking a consultation, or joining a mailing list. Define the device and browser coverage based on the audience and traffic data. Record the form version, viewport, test account, and expected result so later tests can be compared.

Use realistic but non-sensitive test data and avoid submitting real customer information during routine QA. If the form connects to a CRM or payment flow, agree on a safe test mode or cleanup process. A test should exercise the full route without accidentally contacting customers or creating genuine transactions.

Observe completion without coaching

Ask a tester to complete the task and narrate what they expect each field to do. Observe hesitation, scrolling, keyboard changes, validation errors, and uncertainty about required information. Avoid telling them where to tap unless the purpose is specifically to test support instructions.

Measure completion, time, errors, abandoned steps, and points where the tester asks for help. These numbers are diagnostic signals, not universal pass thresholds. Pair them with short notes about what caused difficulty, such as unclear labels, unexpected formatting, or a button hidden by the keyboard.

Test input and error recovery

Check email and phone formats, address fields, date pickers, select menus, required fields, and any local-script input that the intended audience may use. Confirm that error messages explain the problem and how to correct it. Preserve valid inputs after an error where practical so users do not need to restart.

Test slow network conditions, accidental double taps, interrupted sessions, and return navigation when these conditions matter to the journey. Verify that the submit button provides a clear response and that users cannot unknowingly submit duplicate requests. If a field has a strict format, show an example before the user makes a mistake.

Check accessibility and confirmation

Test keyboard and assistive-technology access where relevant, visible focus, label associations, contrast, zoom, and screen orientation. Make sure the page does not rely only on colour or placeholder text to communicate meaning. The appropriate checks depend on the interface and applicable accessibility requirements.

After submission, confirm that the user sees a clear success state, understands the next step, and can find any promised reference number or contact route. If the form fails, make the failure visible and tell the user whether retrying may create a duplicate. Check the actual confirmation page or message, not only the backend record.

Turn findings into release criteria

Log each finding with a screenshot or reproducible step, impact, owner, fix, and retest result. Prioritise problems that prevent completion or cause incorrect submissions. Re-run the same script after material changes to field order, validation, embedded tools, or mobile layout.

Use a small set of consistent test tasks across releases, and add targeted scenarios when analytics or support complaints reveal a new issue. Keep the script current with the form's real purpose; a form that collects a quote request has different success criteria from a checkout or event registration.

Worked example

A mobile quote form looks fine on a desktop but its phone-number field triggers the wrong keyboard and clears the value after a validation error. A tester records the issue, engineering changes the input behaviour and preserves valid fields, and QA repeats the same task on two common mobile browsers. The release owner also verifies the confirmation state and the lead arriving in the CRM.

Implementation review

Usability tests with a few participants reveal friction but do not prove that every customer will behave the same way. Combine direct testing with funnel data and support feedback. Keep test records privacy-safe and verify any accessibility claims against the relevant standard and scope.

Key takeaways

• Test realistic tasks on actual mobile layouts and common browsers.
• Observe hesitation and error recovery, not only successful submission.
• Verify confirmation, CRM receipt, accessibility, and duplicate prevention.

Conclusion and next steps

Use the same task script after material changes and compare findings with real funnel behaviour. Fix blockers before polishing minor details, and keep test records free of real customer data. A consistent test makes regressions easier to spot across releases.