AI app guides
Write form errors that help people finish the task
Tell users which field needs attention, how to correct it and whether their previous work has been preserved.
Zocri · 2 min read · Sources checked
Explain the correction in context
W3C's form tutorial recommends identifying invalid fields and providing guidance for correcting errors. For a generated service form, replace a vague invalid input message with a useful instruction tied to the relevant field. If a contact method is required, say which accepted options the person can provide. Avoid making them infer the rule from repeated failed submissions.
Decide whether the error concerns the person's input or the app's ability to save it. These need different responses. A missing date can be corrected in the form; a temporary service failure may require a retry. Do not blame a customer for an error they cannot fix by editing their information.
Preserve what was already entered
When one field is wrong, keep the other valid values where appropriate. A user should not need to rewrite a detailed description because a date was missing. If sensitive data must be cleared for a specific reason, explain the necessary re-entry rather than silently emptying the whole form.
Place the message where the person can connect it to the field, and make the overall failure noticeable. Long forms may need a summary that helps users reach each problem. Use text and appropriate programmatic relationships rather than relying only on color to signal what needs attention.
Be precise about submission state
After a failed save, tell the user whether the request exists. Saved with an attachment still missing is different from not saved at all. A generic something went wrong message can lead to duplicate submissions when the first attempt actually created the record.
For success, state the next step and the reference the user can keep. If review is pending, say so. Avoid calling the request confirmed when it only entered a queue. The language after submission should match the owner's state and any message sent through an external service.
Review the form with awkward inputs
Try an empty required field, a long valid value, a mistyped contact detail and a temporary save failure in a safe environment. Check keyboard movement, message visibility and whether the person's input remains. Inspect the narrow layout as well as the desktop view if both are in scope.
Have someone unfamiliar with the form correct each error without coaching. Record where they hesitate and refine the wording or placement. Good errors make the next useful action clear and keep the person oriented, while leaving broader accessibility and implementation checks as explicit parts of the review.