Part Three: The details · Asking and deciding
Accepting anything and complaining afterward is the easy thing to build. People would rather be unable to make the mistake, or have the product accept what they typed.
The cheapest form to build takes whatever is typed, sends it off, and reports back what was wrong. Someone booking a clinic appointment fills in eight fields, presses the button, and gets the page back with red text: "Phone: numbers only." They had typed 555 014 2233, with spaces, the way phone numbers are written.
That moment holds two failures. The first is the product being fussier than it needs to be. A phone number with spaces is still a phone number. A card number typed in groups of four, a postcode in lower case, a price with a currency sign: a person would understand all of these, and software can too. Rejecting them makes people do the machine's tidying.
The second is that a mistake was possible at all. A date typed as 3/4/26 is March 4 in Ohio and April 3 in Leeds, and no amount of tolerance can tell which was meant. So do not ask anyone to type it. Offer the days that can be booked, with the month spelled out. If the clinic is closed at weekends, weekends are not on offer. A choice that cannot be made needs no error message.
Some mistakes cannot be blocked, only caught. Write "I've attached the file" in Gmail, press send with nothing attached, and it stops to ask whether you forgot something.
Do not block what you merely find unusual. A real person may have a one-letter surname or no middle name.
Phone
555 014 2233Numbers only.
Appointment date
3/4/26Invalid date format.
Phone
555 014 2233Appointment date
Mon 6 Apr Tue 7 Apr Wed 8 AprClosed at weekends.
Therefore:
Offer only the choices that are possible, and accept every reasonable way of typing the right answer. Where a mistake cannot be blocked, catch it before it does harm.
In practice. Look up which validation errors your product shows most often. For each of the top five, ask whether the control could have made the error impossible, or whether the input was fine and the rule was too strict.
Goes with. What cannot be prevented needs ERRORS THAT HELP (77), and what slips past both needs UNDO ALMOST EVERYTHING (54). The traps are easiest to design out while the idea is ROUGH ENOUGH TO CHANGE (22).
Example: Gmail's forgotten attachment reminder.