The value of cross-device consistency comes from positive transfer

What it is

Keeping operations consistent across devices is often treated as a self-evidently good habit, but its real source of value can be stated precisely: consistent operation lets the motor program a user has already built on the old device carry over to the new one as positive transfer, saving relearning time and reducing early errors. This isn't a vague claim about "better user experience" — it's a judgment call traceable to a specific mechanism with a specific beneficiary. The payoff comes from transfer, not from the word "consistency" itself.

Why it happens

The payoff from positive transfer only occurs where a user has already built a sufficiently stable motor program for an operation, and a stable program only forms through high-frequency, consistent repetition. That means investment in consistency does not pay off evenly across every operation in a product — for high-frequency operations, users have already accumulated a program that can transfer, so keeping the mapping consistent cashes in savings directly; for low-frequency operations used only occasionally, users never formed a stable old program to begin with, so whether the old and new device are "consistent" barely affects learning speed for these, simply because there is little to transfer.

Where it stops holding

The positive-transfer benefit of consistency only holds when the same underlying mapping structure is actually preserved across devices — if visual "look uniform across platforms" is pursued at the cost of mapping consistency (say, changing the operating direction to fit a new device's form factor), not only is the positive-transfer payoff lost, it can trigger the similar-appearance-reversed-mapping negative transfer instead, a worse outcome than not pursuing consistency at all. When a new device's physical constraints (size, sensing channel, grip) genuinely require the mapping to change, forcing the old mapping onto it is no longer a free consistency win — it becomes a trade-off that needs to be evaluated on its own terms.

Applying it

• When building a cross-device consistency plan, first audit which operations in the product are genuinely high-frequency and have already built a stable motor program in users, and concentrate consistency investment on those — rather than applying a blanket rule to every control regardless of priority.
• For low-frequency operations, let the design adapt to the new device's own conditions rather than sacrificing usability on the new device just to claim "consistency across all platforms" — these operations gain nothing from transfer anyway, so consistency there is a purely aesthetic goal, not an efficiency one.
• When a new device's physical constraints genuinely require changing a high-frequency operation's mapping, treat that change as a real decision with a learning cost, and plan a transition approach — don't assume that "it still looks like the same product" automatically waives that cost.

Related

• Same group: A8.24.1 Similar movements with the same mapping produce positive transfer · A8.24.2 Similar appearance with reversed mapping produces the strongest negative transfer · A8.24.3 Transfer is determined by mapping, not visual similarity
• Nearby: A7.13.1 Platform-level conventions and single-product brand conventions carry different transfer strength
• Search terms: cross-device consistency · transfer of training · platform consistency