UX5: Sketches, wireframes and forms
Forms that people complete
🎯You'll be able to
Design forms with visible labels, the right input types, helpful hints and clear errors, asking only for what's needed.
🏠The everyday picture
A good bank teller asks only what they need, one thing at a time, and tells you exactly which box you missed. A bad one hands you a four-page form and says "it's wrong" without pointing.
📘What it really is
-
Ask only what's needed. Every field costs effort and adds privacy risk. SehatSlot needs a name and a mobile number; a reason is optional and labelled so.
-
Visible labels above fields. Placeholders vanish when people type (P2 and P3 forgot which box was which), and often have poor contrast. Use a hint below the label for format.
-
Input types and autocomplete help phones:
type="tel"andinputmode="numeric"show a number pad;autocomplete="name"lets the phone fill it in. -
Accept reasonable formats: strip spaces and dashes from phone numbers instead of rejecting "00000 54321".
- Errors:
- check when the form is submitted (or when leaving a field), not on every keystroke;
- show a message in words next to the field, with an icon, not only a colour;
- add an error summary at the top, with links to each field, and move focus to it;
-
keep what was typed.
-
Group and order: related fields together, in the order people think of them; one column on phones.
📝A worked example
Input: the starter prototype/details.html.
| Starter | Problem | Reference design |
|---|---|---|
placeholder="Name", no label |
Disappears; not a label | <label for="name">Full name</label> above the box |
placeholder="Phone", plain text field |
No number pad; no format | Label "Mobile number", hint "10 digits…", type="tel", inputmode="numeric" |
| Red border on error | Colour only; no message | Message "Enter your mobile number as 10 digits", aria-invalid, summary with links |
| "Submit" | Vague | "Book appointment" |
Expected output: tests 2, 4 and 5 of npm run test:prototype pass. Note that the accessibility checker axe reports only one label
problem on the starter's search page (the checkbox); it accepts a placeholder as a name, which is why test 2 checks for visible labels.
🌍Where it's used
- Account sign-up and checkout, where each removed field raises completion.
- Government applications with long forms split into short pages.
- Health forms where a wrong answer can be serious, so errors need to be very clear.
📝Case scenario
A railway concession form asked for date of birth in three dropdowns. Older applicants scrolled through 100 years and often picked the wrong one. A single text field with the hint "For example, 15 08 1958" cut errors and time.
🖱️Try it
List every field you've been asked for when booking anything online recently. Mark each as needed, optional or unnecessary. Success: at least one field you'd remove, with a reason.
⚠️Common mistakes
- Placeholder as label. Sign: no text above the box. Fix: a visible label, and a hint if needed.
- Rejecting reasonable input. Sign: "Invalid number" for spaces. Fix: strip spaces and dashes before checking.
- Clearing the form on error. Sign: people retype everything. Fix: keep their input and mark only what's wrong.
🛠️For your project
Project 2's tests 2, 4 and 5 check visible labels, worded errors linked to fields and a specific message for a short phone number.
✅Quick check
Why aren't placeholders enough as labels?
Show the answer
They disappear while typing and often have poor contrast, so people forget what the field is.
What should happen after a form fails to submit?
Show the answer
Messages next to each wrong field, a summary at the top with links, focus on the summary, and the typed input kept.