Designing for degraded one-handed use must not tax two-handed work

What it is

Moving pause to an edge, enlarging a button, tucking tools into a corner for a one-handed window—those are allowed. They must not be paid for with two-handed efficiency. When both hands are present, the device on a desk or held by both edges, people should use the whole surface and hit spread-out tools quickly, rather than first fighting a corner UI built for the hand that is not there. Degradation adds a short path for the exception. It does not rewrite the default path to look like the exception. A phone may optimize for one-handed as default. A tablet is the reverse: two hands are default, one-handed is a capability added on.

Why it happens

There is only one primary layout. If that layout is built around a one-thumb arc, both hands present produce three wastes: one hand idle; center and far side empty while tools crowd a corner, so density and accidental hits rise; work that two thumbs could do at once (scroll with one, tap with the other) becomes a queue. Compensations built for one hand—a huge bottom bar, a mandatory bottom gesture strip, every primary button moved lower-right—once persistent, tax two-handed efficiency on every subsequent frame. The right structure is two layers: a default layer spread for two hands or a desk; a degraded layer that, on detected one-handed use or on user invocation, delivers those few critical actions to the near side without dismantling the default. When detection is wrong, it is cheaper to make one-handed reach once more than to detour two-handed use every time.

Studying it

Run the same task in two postures: two-handed hold or desk, and forced one-handed. Compare three UIs—two-handed only, one-handed only, two-handed default plus an on-demand one-handed layer.

Independent variables: which posture the primary layout is optimized for, whether the one-handed layer is persistent or on demand. Dependent variables: completion time and errors in the two-handed condition, completion in the one-handed condition, whether two-handed users complain that “everything is crammed into a corner.”

The critical number is the two-handed condition: a one-handed-only layout should be slower or more error-prone there. A study that only measures one-handed will elect a winner that harms the default. Two-handed users should be the majority of participants, matching the real base rate.

Where it stops holding

If the audience is almost always one-handed (bedbound, only one usable hand), the default assumption may become one-handed and this constraint weakens—but a desk should still be allowed a two-handed layout, rather than locking even the desk state into a corner. A system one-handed mode is a short, user-invoked state; while it is on it may spend some two-handed efficiency, and when it is off it must return to the two-handed layout rather than becoming a new default. A game already built for two thumbs should not add a one-handed bottom bar that covers the controls.

Applying it

• Spread the primary layout for two hands or a desk: tools on both sides, content in the middle. Give one-handed use extra near-side entries or an on-demand layer; do not remove far-side tools.
• Do not make a phone’s bottom gesture bar or a huge one-handed bottom bar the persistent skeleton of a tablet.
• A one-handed mode must be exit-able. After exit, tools return to two-handed positions; do not leave a residue still living in a corner.
• Verify by timing the main path two-handed, then doing the few critical actions one-handed. If the two-handed path got slower or denser for the sake of one hand, take those one-handed entries out of the primary layout and put them on an added layer.

Related

• Within the group: K3.07.1 Tablet size puts one-handed reach out of bounds; two hands are the default · K3.07.2 Clustering key actions on one edge serves a one-handed thumb · K3.07.3 Rotation relocates the one-handed reach zone
• Adjacent: K1.10 One-handed Mode and Large-screen Reach · K3.06 Grip and Occlusion · C2.11 Thumb Reach Zones
• Search terms: degraded mode · two-handed efficiency · exception versus default