Information order should follow real-world logic
Aliases: real-world order · process order · chronological order
What it is
Fields, steps, and lists should follow the order users experience or expect in the real task: event before response, patient before test, origin before destination, cause before result. A match between system and real world is not only about wording — it is also about the temporal, causal, and spatial order in which information appears. Get the order wrong and even the right words still leave the user reassembling the material in their head before they can act.
Why it happens
Real-world order supplies retrieval cues. Users organize memory as event chains, so when an interface places a result before its cause, an approval before the request, or splits data from a single moment across two pages, they must keep reordering the material mentally — which is where omissions, mismatches, and misjudged status come from. Order also shapes defaults and validation: earlier information should constrain later options, such as choosing an origin before the destination list narrows. Reverse that order and validation can only fire at submission, instead of narrowing invalid choices while the user is still filling the form.
The payoff from ordering is not uniform — it scales with how strongly later steps depend on earlier ones. When a later field's valid values are truly determined by an earlier one (origin determines destination, diagnosis determines which tests can be ordered), scrambling the order does more than add memory load: it makes upfront validation structurally impossible, forcing the user to discover the constraint through trial and error. When two fields are genuinely independent — name and phone number, say, where either can come first without consequence — real-world order buys only narrative comfort, and the payoff is much smaller than in a dependency chain; sorting by error rate or entry frequency can beat rigid narrative order in that case. This is why the same advice to "follow real-world order" carries wildly different value across forms: the principle itself is not failing, the dependency strength underneath it has changed.
Studying it
One way to locate the real-world order is narrative retelling: ask users who have never seen the interface to describe out loud the steps they go through to complete the task, record the resulting event chain, and compare it against a candidate interface's field or page order using sequence correspondence or edit distance. This has to happen before users are exposed to any prototype, or with a separate group of true novices, otherwise their narration is contaminated by the interface order they already learned rather than reflecting the task's actual order.
Formal testing compares an order-matched version against a scrambled one, with completion time, page-backtracking count, field-skipping count, and post-submission corrections as dependent variables. For forms with real causal dependencies, also record when validation errors surface — during entry or only after submission. Getting the order right should pull errors forward into the entry phase rather than dumping them all at the end.
Where it stops holding
Real-world logic is not the only logic. Managers may organize by priority, auditors by evidence type, and operations by customer importance; expert tasks may deliberately scramble the narrative order for speed, because experts no longer need order as a retrieval cue. When reality's order is genuinely changed, headings, grouping, and preview must explain the new structure so users do not assume a step is missing.
Two concrete boundaries deserve separate treatment. First, when data is transcribed from a paper form, an upstream system, or customer-supplied material, the "reality" the user is tracking is the physical layout of that source document, not an abstract causal chain — order should follow the transcription source, and when the two conflict, the source wins, or the user ends up shuttling their gaze between two orderings and transcribing more errors. Second, independent fields with no causal dependency get little benefit from forced real-world order, as the mechanism section explains; do not sacrifice entry speed for stylistic uniformity, especially in high-field-count, high-frequency entry scenarios.
Applying it
- Write the event chain from task interviews, then map it to field and page order; for transcription-style entry, map to the source document's physical order instead of an abstract event chain.
- Let earlier fields constrain later ones — date ranges, address hierarchy, and approval chains must not be reversed — and validate as soon as the earlier field is set, narrowing later options immediately rather than waiting for submission.
- For multi-page flows, show completed, current, and upcoming groups so users do not go searching for an input that has not appeared yet.
- Replay tasks and compare interface order against users' spoken narrative order to measure the deviation; for forms with many independent fields, run a separate timing comparison to confirm the enforced order is not slowing entry down.