Forgive user input in the wrong format

Paul Felberbauer

Credit card numbers typically appear on the card in groups of four digits, separated by spaces. This makes the number easier to read and transcribe. Other non-numeric numbers, such as account numbers, also typically have a common display format, often using spaces or punctuation for grouping. This difference, between the data and its presentation, traps unwary product designers.

Credit card numbers

Nearly every web site that sells something has credit card number input user interface. Many get it wrong. Credit card numbers have eight to nineteen digits (Wikipedia), with most card issuers using at least sixteen digits. This presents a tough user experience design challenge, because humans can’t keep long numbers in short-term memory.

The ‘Credit Card Number’ Field Must Allow and Auto-Format Spaces (80% Don’t) notes that ‘test subjects were often observed to enter their number in the same format in which it is embossed or printed on their physical card’. Sadly, many web page forms don’t allow this, and appear on the “No Dashes Or Spaces” Hall of Shame.

Post codes

Post code inputs have the same problem. In Geen-spaties-in-postcode Hall of Shame (in Dutch, translated), Kees de Kooter explains how this goes wrong.

1. A Dutch post code consists of four digits, a space, and two letters, e.g. 1234 AB.
2. A developer stores the post code in a database without the space, e.g. 1234AB.
3. The developer mistakenly thinks the input format must match the storage format.
4. The resulting form validation rejects user input that uses the display format, e.g. 1234 AB.

It doesn’t help that frameworks for building web sites typically include built-in code for rejecting ‘invalid’ user input, but not for normalising ‘numbers’ and codes to their canonical formats. It also doesn’t help that most countries have more complex post code formats (while several smaller European countries only use four digits).

Normalise user input

When people enter credit card numbers, allow them to use spaces and automatically remove them later, to improve usability. The same applies to other kinds of data with few significant characters, such as phone numbers. Instead of rejecting user input that doesn’t conform to your storage format, accept variant but equivalent formats for unambiguous data.

Similarly, remove spaces and line breaks at the start and end of most text input - ‘insignificant white space’. But beware of exceptions, and kinds of data that require more care.

Be extra careful with money amounts, where typos can have larger consequences. For example, when someone inputs the amount 1,0000 they might have intended 10,000 or 1,000. In general, don’t make guesses about ambiguous input; instead show a warning.

Don’t assume the same format for input, storage and display.

Separate input, storage and display formats

Don’t assume the same format for input, storage and display. Each has multiple possible formats, and they change for different reasons.

• Input formats vary from person to person.
• Display formats vary by region (locale).
• Storage formats vary by software system.

Accept any unambiguous input, store it in one normalised format, and display it in the user’s chosen regional format. And more generally, understand and apply the robustness principle.