In multi-person collaboration, sharing one layout outweighs individual switching gains

What it is

When more than one person takes turns on the same keyboard—pair programming, a shared front-desk PC, a classroom machine, a nurses' station—layout choice stops being a private speed problem. Sharing one layout lets anyone sit down and type, skipping remap, legend matching, and shortcut explanation. An individual switch to a theoretically faster map turns the next collaborator into a novice. The more frequent the handoff, the more that compatibility gain swamps any private keystroke savings.

Why it happens

Private switching gains accrue inside one person's repeated sessions, in milliseconds per keystroke and a few fewer corrections. Collaboration cost hits every handoff: legends disagree with the software map, someone trips a foreign shortcut, or a system layout is changed and not restored. Handoffs scale with pairing, shift work, hot-desking, and remote assistance; private gains do not scale with headcount. On a solo laptop a remap can still pencil out. On a shared terminal the optimum is almost always “everyone uses the map they already know.” That does not refute speed claims for alternatives; it changes the objective from solo throughput to handoff friction.

Studying it

Split solo versus shared use rather than recruiting only skilled typists for transcription. Independent variables include how many people can operate the device, mean handoff interval, whether system remapping is allowed, and whether printed legends match the software map. Dependent measures must include handoff time, accidental remaps, and the next user's first-sentence errors, not only per-person WPM. Field observation matters more than the lab: hospital, counter, and exam-room keyboards are rarely remapped, and that fact is data. Measuring “speed after a month of remapping” in a cubicle systematically undercounts the collaboration penalty.

Where it stops holding

On a machine that is never borrowed, the collaboration term is zero and a private remap can be costed alone. Remote desktop that locks layout on the server creates a different fight between local legends and remote mapping. A team that trains together on a non-default layout still harvests sharing gains—they have merely locked onto another standard. Touch devices usually give each person a software keyboard, but handing a phone to someone during a demo is still a brief share.

Applying it

• On hot desks and classroom machines, do not write a personal layout into the system default; keep preferences in the login profile or a removable config.
• In pair programming, agree on a host layout and keep the external board mapped to it, so one person is not on Colemak reading QWERTY legends.
• Before remote assistance, confirm both layouts, or offer a “press by legend picture” fallback instead of assuming identical letter positions.
• Verify by having two people take turns on one machine for a real edit, timing from sitting down to the first correct sentence. If remapped machines hand off much more slowly, do not push that remap onto shared devices.

Related

• Same group: C6.17.1 QWERTY originally separated keys to avoid typebar jams, not to match modern key actuation · C6.17.2 Keyboards no longer jam, yet layouts stay locked by network effects rather than engineering constraints · C6.17.4 OS and app defaults that preinstall a layout reinforce the same path dependence
• Adjacent: C6.01 QWERTY and layouts · C6.19 Touch typing and homing references
• Search: shared keyboard · hot-desking · layout compatibility