Put the zip code first

Original Article ↗ Hacker News Discussion ↗

A viral UX rant argues that address forms should ask for the ZIP/postal code first and auto-fill city, state, and even country, claiming this would eliminate clumsy country dropdowns and speed up checkouts. Commenters largely agree that using high‑information fields to prefill others can be helpful, but point out numerous edge cases: ZIP codes that span multiple cities or states, non‑US postal formats, countries without postcodes, and legal or logistical needs for precise locality data. Many conclude that country must still come first for global services and that browser autofill or free‑form address fields often provide a more robust, less error‑prone solution than aggressive ZIP‑driven automation.

Core proposal: ZIP/postcode first

  • Many agree the basic idea—using a high‑information field early to auto-fill city/state/country—can reduce typing and feel snappier.
  • Several note this is already common in some countries (e.g., UK, NL, IE, JP) where postcodes are fine-grained and backed by good postal databases.
  • Some suggest a refined pattern: country first (possibly prefilled via IP), then postal code, then the rest.

Limitations of ZIP codes (even in the US)

  • Multiple comments stress: ZIPs are about delivery routes, not political boundaries.
  • ZIPs can:
    • Map to multiple cities and even multiple states.
    • Change over time.
    • Cover PO boxes only or unusual entities (boats, large campuses).
  • USPS treats each ZIP as having a “preferred” city and alternates; mail works even with “wrong” city, but legal/municipal boundaries often differ.

International & format issues

  • Many point out that:
    • “ZIP code” is US‑specific; other countries use postal codes with different formats (length, letters, digits, or none at all).
    • Numeric-only inputs and 5‑digit assumptions break for Canada, much of Europe, etc.
    • The claim that 5 digits determine the country is flatly rejected; the same codes exist in multiple countries.
  • Non‑US readers often see US‑centric design as actively hostile or unusable.

UX, autofill, and validation

  • Several argue built‑in browser autofill is simpler and often superior: no typing at all if forms are standard.
  • Over‑eager validation and “corrections” frequently reject valid foreign addresses or diacritics, causing drop‑offs.
  • Auto-fill should be suggestion, not hard validation; users must be able to override guessed city/state.

Data & implementation complexity

  • Maintaining accurate global postcode→place mappings is non‑trivial; commercial datasets are incomplete, expensive, and change.
  • For US‑only or single‑country sites, ZIP/postcode‑first can work well if backed by postal data and still editable.

Alternative approaches

  • Some favor:
    • Country → postcode → structured fields (with soft autocomplete).
    • Or even a single free‑text, multi‑line address box parsed server‑side.
  • Others note address entry isn’t a huge burden; “clever” flows often fail more than they help.

Tone and reception

  • Many criticize the original site’s US‑centric framing and later snarky geo‑targeted messages as condescending.
  • Nonetheless, several commenters see merit in the underlying principle if adapted carefully and globally.