The two layouts' muscle memories conflict, and mixed use raises entry errors

What it is

A hand trained on a calculator array, meeting a telephone array, applies a “up means larger digits” program to a surface where up means smaller digits. The misses are not neighbor slips; they are row-swap errors: intending 1 and landing on the row that holds 7. The reverse is the same. Both layouts share the middle row 4-5-6, so conflict concentrates on 1/7, 2/8, 3/9, and the place of 0. Switching among an ATM, a phone, and a lock pad in one session raises errors above using either layout alone.

Why it happens

Number-entry motor programs encode relative row, not the semantics of the Arabic digit. The two arrays place 1 and 7 in vertically symmetric seats, maximizing negative transfer. The shared middle row creates a “close enough” illusion, delaying detection that the wrong model is in use. A cashier who types amounts on a numpad all day and dials a phone at night has two programs fighting for the same right hand. Experiments that only measure absolute speed on one layout never see the interference; it lives in the first keystrokes after a switch and can grow under pressure (PIN, time limit).

Studying it

Train to stability on one layout, then swap suddenly, and in the first N keystrokes score row-swap errors (1↔7, 3↔9) against ordinary neighbor errors. Independent variables include training amount, delay between layouts, and whether the task is amounts or telephone numbers. Use 4-5-6 as a control: middle-row errors should not rise the same way after a switch. Field diaries between a real ATM and a phone are possible. Do not dump every error into “number pads are hard,” which mixes interference with small keys and gloves.

Where it stops holding

People who only use phones, never calculators, have no this pair of negative transfer; their baseline errors have other causes. Experts on both can switch models by scene; interference shrinks but still leaks when tired. Voice input and paste bypass the array and produce no row swaps. If the two arrays look extremely different (color, size), interference falls, but most lock screens and ATMs are both cool-colored square keys with too little distinction.

Applying it

• Do not use opposite row orders for payment amounts and telephone numbers inside one product.
• When both must exist, give the model switch a cue: a differently placed 0, or an explicit “dialer / calculator” title.
• For high-cost digits (PIN, transfer) in mixed-device environments, offer paste or scan to reduce live blind tapping.
• Verify by having someone who just used a computer numpad immediately type a string containing 1 and 7 on the product dialer, scoring row swaps separately. If those dwarf neighbor errors, the problem is interference, not key size.

Related

• Same group: C6.23.1 Calculator keypads run 789/456/123 top to bottom; telephone keypads run 123/456/789 · C6.23.3 Choose a software keypad layout that matches the device type users know in that scene · C6.23.4 If digit positions are not unified across platforms, experience becomes inconsistent
• Adjacent: C6.19 Touch typing and homing references · C6.29 Dedicated password keyboards
• Search: layout interference · negative transfer · numeric keypad errors