WEBSITE PLANNING

Write Form Errors People Can Recover From

Plan useful validation messages, preserve customer input and verify that people can recover from form errors.

Collect the recoverable failures

List errors customers can reasonably encounter: a missing reply address, an unsupported file, an expired form or a service selection that is no longer available. For each, write what the person needs to change and whether their existing work can be preserved. Avoid a generic Something went wrong when the application already knows which field needs correction.

Write the correction in plain language

Compare Invalid input with Enter an email address so we can reply. The second explains the action without implying the customer has done something wrong. For an attachment, name the allowed file types and size before the person selects a file. Keep errors close to the relevant field and ensure their meaning does not depend on red color alone. W3C’s validation guidance also notes that server-side validation remains necessary.

Test without polluting live leads

Use an agreed test environment or explicitly authorized labeled cases. Record the starting values, error, focus behavior and whether previously entered information survives. A useful acceptance condition says that the customer can identify and correct the problem using a keyboard, then proceed. Do not use real customer information in screenshots or analytics event labels. Recheck recovery, not just whether an error appears.

Reference and next step

Reference: W3C form validation tutorial. For help reviewing a specific implementation, send the affected website address and describe the task customers are trying to finish.