Order must be consistent inside one product

What it is

The platform supplies a confirm/cancel slot; a product still has to use one slot inside its own boundary. OK on the right in Settings, on the left on Uninstall, and Delete sitting in the confirm slot of a bulk bar is in-product inconsistency. People cannot compile place memory for “this app”; every dialog is a new problem. Consistent order is transferable skill inside the product. Crossing platforms is a different point.

Why it happens

Skill converges on stable statistics. If a product’s own statistics are noise, the learning curve flattens: neither the Windows set nor the Mac set is learned, only per-dialog reading. Inconsistency is rarely a decision. Feature teams copy dialog templates from different eras; Web and native each follow their host. Users do not see template provenance; they see “this software’s OK is sometimes here and sometimes there.” Without a baseline, a one-off swap meant as a deterrent cannot even be noticed—there is no “normal order” to deviate from. Only after internal unity is an exception readable as a warning.

Studying it

Walk the product: collect every surface with a confirm/cancel (or primary/secondary) pair, code left-right or top-bottom order, count disagreeing pages. Then task people on a version with one order versus a version that mixes two.

Independent variables: whether in-product order is single, density of disagreements. Dependent variables: whether speeding-up starts at the second or third similar dialog, wrong presses, ratings of “this app is messy.”

The walkthrough comes before the experiment. Many products never show their inconsistency in the two pages a lab task happens to use.

Where it stops holding

Embedded system dialogs (file picker, permission) force OS order. An app dialog beside one of those will briefly disagree; keep them off the same screen when possible. A Web admin used across OSes should unify internally before trying to follow everyone’s OS; following the OS is the cross-platform problem. An A/B test that uses order as a variable manufactures inconsistency in the treatment; the experiment must converge when it ends.

Applying it

• Put the confirm/cancel slot in one dialog component; feature teams do not lay out their own row.
• List every paired action (save/cancel, allow/deny, delete/keep) and encode them in one direction.
• When historic pages disagree, migrate once; do not leave an “old settings” order.
• Verify by stacking screenshots of every pair. More than one left-right or top-bottom pattern means in-product order is not unified.

Related

• Within the group: E1.10.1 Confirm and cancel swap left and right across platforms · E1.10.2 A scrambled order makes automatic actions miss
• Adjacent: E1.18 Button order and platform conventions · B2 Design principles · R1 Design systems
• Search terms: internal consistency · button order · dialog footer