Evaluate forms through a complete task
A fictional form comparison shows what remains open after design approval: correction, retained input and confirmed receipt.
A form can look understandable in a design discussion and create extra work when an entry is corrected. Approval should therefore record which part of the flow was actually assessed and which questions remain open.
The same inquiry, different flows
The following table describes assumed behaviour in two fictional project forms. Their initial views look equally orderly. Both label the phone number optional; the person wants to submit an inquiry that allows follow-up by email.
Check case | Version A | Version B |
|---|---|---|
Phone field stays empty | Still treated as required on submission. | Remains optional. |
Email is incomplete | Only a red border, no help with correction. | Understandable error text with a route to the field. |
Email is corrected | The previously entered project goal disappears. | The project goal remains. |
Transmission is unconfirmed | Success appears immediately after the click. | Receipt is shown as still unconfirmed. |
Discussing the initial view alone does not reveal these differences. The form’s appearance and behaviour during the task must therefore be considered together. W3C WAI explicitly treats feedback beside fields and on submission outcomes as part of the form flow.
Distinguish observation from functional checks
GOV.UK describes usability testing with specific tasks and clear, neutral instructions. For this example, the goal could be: “Submit a project inquiry that lets the team contact you by email.” Observe whether the person reaches the goal, where they hesitate and what help they need. The instruction does not reveal which button to choose next.
A prepared functional check additionally targets incomplete input and a missing server confirmation. It can show, for example, whether values remain. A technically exercised error case is not an observation of actual users. The two types of findings answer different questions.
What early design approval can establish
A visual design helps assess wording, information hierarchy and the proximity of hints to fields early. If flows have not been built, a clickable prototype can make correction paths understandable. Server acceptance must be marked as an assumed state there.
For later approval, the complete path to confirmed receipt becomes important, including agreed error cases. A clear approval note therefore names the task checked, the last confirmed state and the open issues.
Sources
Read more
All articles
Design & UX with ASES
User experience, interfaces and brand presence