A cross-platform product should follow each OS’s order

What it is

A product that ships on Windows, macOS, iOS, and Android should not use one global confirm/cancel slot—the one on the designer’s laptop. A cross-platform product should follow the host OS at runtime: Cancel left and confirm right on a Mac, the reverse on Windows, Cancel sunk alone at the bottom of an iOS action sheet. What is adapted is the slot mapping, not a full visual redraw per OS. The product is still internally consistent—consistent at “always follow the current OS,” not at “always confirm on the right.”

Why it happens

Place memory is bound to the daily OS, not to a brand. One global order puts half the users on the wrong-handed slot on every side, and habituation slips split by platform population. Web apps fail this easily: they live in the browser and still render the mock’s macOS order to Windows users. A native shell can read a system API; a page needs platform detection or system integration, and a wrong detect (iPad reported as Mac) applies the wrong set. Adaptation is not an aesthetic compromise. It leaves skill at the OS layer; the product only claims “we are a window on this system.” Not adapting forces a brand-specific slot that fights every other window.

Studying it

Run the same build on Windows and macOS (or iOS and Android) for a timed confirm, comparing follow-OS with one global order (the designer’s side). Stratify by daily OS.

Independent variables: whether it follows the host, whether detection is correct, dialog versus sheet. Dependent variables: whether wrong-press rate rises only in the mismatched OS stratum.

Testing only on the company’s standard laptop will always conclude “our global order is fine.”

Where it stops holding

A Web admin with mixed OS users and unreliable detection may prefer internal unity to random swaps from bad detection—random is worse than “always wrong in one direction.” Embedded system dialogs already follow the OS; an app dialog that deliberately follows another set will fight a system picker on the same screen. A fullscreen game that builds its own UI is not expected to use OS slots and may be self-consistent, but a desktop settings window that looks like a system dialog should follow the OS again. A marketing site can ignore OS; it is not a productivity dialog.

Applying it

• Native apps should call system dialogs or read the OS button-order setting; do not hard-code left/right in a resource file.
• On the Web, follow the host when it can be known reliably; when it cannot, pick one order, keep it site-wide, and avoid sitting beside a system file picker.
• When adapting order, keep visual-weight rules: the primary is still high weight, only the slot changes.
• Verify the same account doing a timed save on two OSes. When follow-OS works, wrong presses should cluster on a build whose order contradicts that OS, not spread evenly.

Related

• Within the group: E1.18.1 Default focus should land on a non-destructive option, not on danger · E1.18.2 Bottom sheets and centered dialogs may follow different button-order conventions · E1.18.3 The default button fired by Enter must not be a destructive action
• Adjacent: E1.10 Button order · R4 Platform conventions · K8 Cross-device
• Search terms: platform convention · adaptive dialog · OK Cancel order