Design How Identifiers Appear in the Interface

Systems & Architecture · apis, microcopy, support

Updated 2026-08-04

Expect internal identifiers to be long, unordered, and unfriendly. Systems that generate ids across many machines cannot use a neat counter, so the value you get is a large number or a random-looking string.
Never let a raw identifier be the only thing a person can refer to. If support, the user, and the logs all need to point at the same record, that record needs a reference someone can read aloud.
Give user-facing records a short, checkable reference and keep the internal one behind it. Orders, tickets, and invoices are read over the phone and copied into emails.
Never imply an order or a total that the identifier does not carry. A sequential-looking number tells competitors your volume, and a non-sequential one tells the user nothing, so neither should be presented as a count.
Make every visible identifier copyable in one action, and confirm the copy. People will otherwise transcribe it by hand and get it wrong.
Format long values for the eye. Grouping or truncating with the full value available on demand beats a 26 character string running into the next column.
Keep the identifier stable for the lifetime of the thing it names. An id that changes when a record is edited breaks every link, bookmark, and support note that referenced it.
Show identifiers where a person would look for them, which is the detail view, the receipt, and the error message, rather than only in a developer panel.

An identifier is part of the interface as soon as a human has to repeat it.