Plan project forms with clear fields and error messages

A long project form is easier to revise purposefully when the next work step is clear. First establish which details the team actually needs for that step. Then plan labels, validation and feedback together.

Start with the next work step

In the fictional portal below, the team needs to classify an initial software inquiry and ask follow-up questions by email. Project title, project goal and email are therefore required. The phone number remains optional. Billing address and internal customer number are not required for this initial inquiry. This is a decision for the example flow.

W3C WAI recommends asking only for details necessary for the process concerned. Every remaining question needs an understandable purpose.

Keep field text visible

Labels remain visible during entry and are programmatically associated with their fields. A placeholder in an empty field does not replace the label: it disappears when typing. Purpose and optionality are therefore explained beside the field.

“Optional” must agree with validation on submission. An empty phone field must not cause an error in this flow.

Tie errors to the specific situation

For this form, validation is planned on submission. Missing details, incomplete entries and an unconfirmed transmission receive different feedback.

A format check does not confirm that the mailbox is reachable. A transmission problem is not presented as an incorrectly completed email field.

Allow correction without losing data

After an input error, the design provides an error summary that receives keyboard focus and links to the affected field. The same understandable error text appears beside the field; assistive technology must be able to associate it too. Existing values remain, including the entry to be corrected.

A success message follows only after the server confirms receipt. If the result is unclear, the resubmission flow must establish how to recognise an inquiry that may already have arrived.

Check a complete task

Have the example inquiry completed without a phone number. Also check the error path with an incomplete email: can the message be found, the address corrected and the inquiry completed while the project goal remains? Include keyboard use, a narrow screen and the assistive technology in use. Record where someone needs help and whether receipt is actually confirmed at the end.

Sources

• W3C WAI — Forms Tutorial

• W3C WAI — Form Instructions

• W3C WAI — User Notification

• GOV.UK — Recover from validation errors

• GOV.UK — Email addresses

• GOV.UK — Moderated usability testing