Map the journey
List entry, required fields, help, attachments, consent, submission, error, success and follow-up message.
GUIDE / PROTOCOL
A form works when a person understands the request, can correct errors and knows what was submitted.
Direct answer
Walk through every form state with keyboard and mobile. Check the need for each field, clear labels, errors, server-side validation, data retention and the confirmation actually received.
01 / Review method
List entry, required fields, help, attachments, consent, submission, error, success and follow-up message.
Try valid, empty, long, international and invalid values; review labels, examples, tab order and preservation of entered data.
Inspect server-side validation, targeted errors, duplicates, network failures, repeated submissions and timeouts.
Verify acknowledgement, functional recipient, stated timeline, stored data and the ability to resume without needless re-entry.
02 / Evidence to keep
Inputs, expected state, displayed message and observed outcome for each case.
Labels, help, focus, errors, summary and confirmation on mobile and keyboard.
Response status, timestamp and test identifier without real personal information.
Barrier, task impact, fix, owner and retest.
AFTER THE REVIEW
Treat data loss as a journey failure. Preserve non-sensitive values, focus the error summary and retest correction.
Do not mark the journey complete. Check the server response and actual processing with fictitious data, then fix the message.
03 / FAQ
No. It helps immediate feedback, but validation is also required on the server.
Yes, clearly before input and in error messages.
Explain the fix, connect the message to its field and retain other values where possible.
Use fictitious cases and check minimized logs.
04 / Official references