Numbers, dates, and units should follow users’ local conventions

What it is

Numbers, dates, times, currency, addresses, phone numbers, name order, and units of measurement should be presented according to the user's region and business context. Locale conventions determine whether 03/04/2026 means March or April, whether the thousands separator is a period or a comma, and whether distance is shown in kilometers or miles. This card's relationship to the other three in the group: those cover mismatches a user notices immediately, such as vocabulary or a broken metaphor; this one covers the most dangerous kind of mismatch — one where misreading a number or date usually goes completely unnoticed, because the misread value is still a perfectly valid one.

Why it happens

Format errors are more dangerous than other mismatches precisely because they rarely show up as "I don't understand this" — they show up as "I understood this, just as the wrong thing." Whether 03/04/2026 is read month/day/year or day/month/year, either reading produces a real, syntactically valid date; the system's format validation raises no error, and the user has no way to notice the ambiguity either. The mistake is therefore never caught at the moment of entry — it flows downstream unchanged until it collides with another system's or another person's record, and by that point it is very hard to trace back to the original misreading. This is why localizing dates and numbers cannot be treated as a purely cosmetic localization task: a typo gets caught by validation, a format misread does not — it disguises itself as a perfectly ordinary answer and lies dormant.

Where it stops holding

Not every context should display in the individual's own locale, and not every user's calendar system is Gregorian. International contracts, flight schedules, scientific data, and financial transactions may require ISO 8601, UTC, three-decimal precision, or dual-unit display, and such contexts should explicitly label the format standard rather than implicitly relying on the user to guess. Locale convention is also not a single Western-format-variation dimension: users in some regions routinely use a non-Gregorian calendar (Buddhist, Islamic) or a non-Arabic numeral system, and an interface "localized" only around the Gregorian calendar and Arabic numerals is still a foreign format to them. Conversely, some contexts must deliberately break the "follow the user's locale" default — safety-relevant values such as medical dosages or engineering tolerances should keep a metric figure with an explicit unit in the authoritative record even when displayed to a user accustomed to imperial units, because when clinicians or engineers from different backgrounds exchange the data, a unified unit matters more than accommodating individual habit; here, "match the user's world" yields to "match cross-role collaboration safety."

Applying it

• Separate the format layer from storage: locale, language, currency, calendar, time zone, unit, and numeric precision can vary at display time, but the stored value must remain unambiguous and canonical (an ISO 8601 date, a metric figure with an explicit unit).
• Support local input formats and echo back the parsed interpretation immediately — after a user types 03/04/2026, show "that is March 4, 2026" right beside it, so they can catch a misparse before submitting. Where dates are inherently ambiguous, prefer a month name or a calendar picker at the entry point to remove the ambiguity outright, rather than relying on echo-back correction after the fact.
• For safety-relevant or cross-role values (dosage, engineering tolerance, contract amount), keep an unambiguous canonical format displayed alongside any localized presentation, so people from different backgrounds can cross-check it.
• How to check: test input, sorting, export, printing, and screen-reader reading with real sample data from the target locale — pay special attention to sorting and export, since these two steps most often treat a date or number as a plain string during format conversion, producing a result that looks correct visually but sorts or computes incorrectly.

Related

• Same group: B3.14.1 The match targets users’ world, not the designer’s or the engineering implementation’s world · B3.14.2 Metaphors necessarily break where they exceed the original object’s properties; define their boundary in advance · B3.14.3 Terminology consistency outranks terminology accuracy; synonym rotation is read as different concepts
• Nearby: S1 Internationalization and Localization · I1 State, Time, and Response
• Search terms: locale format · internationalization · units of measurement · date ambiguity