Hit targets must follow touch size, not mouse size

What it is

The tiny close button in a laptop title bar is easy with a mouse. A finger pad landing on it often hits maximize, or the window-edge drag strip. Touch-sized targets means: if this screen accepts a finger, a desktop app’s hit areas follow the finger pad, not the density that pointer precision would allow. Minimum target size is a separate physical constraint in the touch channel; this entry is only the mixed-desktop case of chrome that is still sized for a mouse.

Why it happens

A pointer’s effective width is close to a pixel; people can visually park it inside a target before pressing. A finger is a contact patch that the system then collapses to a point, so aiming error and neighbor competition arrive together. Desktop apps grew up assuming a cursor: 16-pixel icons, flush close buttons, icon rows with no gap. Those hold with a mouse because the cursor can sit inside a target without covering it. A finger both occludes and overshoots. If center-to-center spacing still follows mouse packing, the hit distribution lands on the neighbor. The hybrid failure is not “there is no touch edition.” It is desktop density wired onto glass that can be touched. Drawing the glyph small while inflating the hit area only eases occlusion; it cannot stably separate two 8 mm-wide targets whose centers are 8 mm apart.

Studying it

On the same touch-capable desktop hardware, run pointing tasks with mouse and with finger on one UI, rather than citing phone target floors alone. Compare keeping desktop packing against enlarging toolbar, caption buttons, and list row height until they are finger-separable.

Independent variables: visual target size, actual hit size, neighbor spacing, input channel (mouse / finger), whether the target sits on a screen edge. Dependent variables: first-hit rate, neighbor errors, completion time, how often people abandon touch for the trackpad to avoid misses.

Do not substitute “a platform published a recommended pixel value” for measurement. Failures on hybrid devices cluster in leftover desktop chrome, not in page-level primary buttons already sized for phones. If the lab lets people switch back to a mouse at will, finger-condition abandonments are logged as “task still completed.” Either constrain a stretch to touch only, or split errors by pointer type in the log.

Where it stops holding

Keyboard-mouse workstations that never see touch can keep pointer density; enlarging everything hurts expert scanning. A capacitive stylus shrinks the contact patch and the pressure approaches mouse-like, so this claim weakens. Products that already ship a sparser touch layout and a dense mouse layout have their conflict at the layout switch, not inside one density. Game HUDs and grading palettes that must keep a whole set on one screen accept smaller targets, but they still need mouse or pen as the fine channel.

Applying it

• Size desktop chrome that will be used under touch (window controls, primary toolbar buttons, list rows, segmented switches) for finger-separable size and spacing, not only the page’s main action button.
• The glyph can stay desktop-styled; the hit area cannot shrink to the icon’s visible pixels. Targets on edges and corners need extra room for finger slip.
• Do not defend dense packing with “they can always switch to a mouse.” Switching input has a cost; density drives people off touch.
• Verify: unplug mouse and trackpad and complete save, close, tool switching, and list selection with a finger only. Every neighbor miss marks a row still packed for a mouse. Plug the mouse back in and confirm the extra spacing did not add a pointless extra pointer travel for keyboard-mouse users.

Related

• Within the group: K2.07.1 The same device can switch between two input methods · K2.07.3 Switching input methods needs immediate adaptation
• Adjacent: C2.02 Minimum touch target size · C2.03 Minimum spacing of touch targets · J3.04 Touch-target floor
• Search terms: touch target size · hybrid desktop · finger-sized chrome