F6.04.3hit area vs icon sizedesignresearch

Icon size is independent of hit-area size

Aliases: hit target · tap target · hot zone

What it is

The 16 px drawing is for seeing. The finger hits a larger hit area underneath. Each size answers a different question: the glyph, whether it can be identified; the hit area, whether it can be acquired. Enlarging the drawing "so it is easier to tap", or shrinking the hit area to the path "so it looks tighter", merges two ledgers into one. Icon size and hit-area size have no conversion factor. They merely often share a control.

Why it happens

Pointing difficulty is set by the effective width of the target and the distance to it, not by the visible strokes. A fingertip is far larger than a small outline; if the hit area hugs that outline, usable width is cropped by the drawing and miss-taps land on the neighbour. Inflating the drawing to fill the hit area does the opposite: it spends identifiability on pointing difficulty, so the picture melts while the tap gets easier. The two limits have different sources — pixels and parts versus movement and contact patch — so there is no need for "edge equals hot zone". A desktop cursor hotspot is smaller, and the hit area may still outrun the drawing to leave room for miss-aim; on touch that margin is simply larger.

Studying it

A Fitts-style pointing task can split visible glyph edge and tappable rectangle as two independents. Acquisition time follows the effective target, not the visible square — provided the hit area is actually responding. False misses are equally diagnostic: a large drawing over a still-tiny default responder makes people aim at the size they see and tap "empty" pixels that look as if they belong to the icon. Dependents: time, error rate, spatial distribution of dead taps. Log both the visible box and the responder; reporting only one means the split was never made.

Where it stops holding

  • If the drawing is obviously smaller than the hit area and no other boundary (a fill, a frame, a whole list row) shows, people underestimate the tappable range and aim at the outline. Expose the hit area through the container rather than fattening the drawing.
  • Neighbouring hit areas must not overlap. The ceiling on growth is the gap to the next control, not "bigger is better".
  • A melted drawing is a detail-density problem. A larger hit area will not restore identification.
  • This forbids merging the two ledgers. It does not say whether a small size needs its own master.

Applying it

  • Specify separately: glyph edge by identification, hit area by pointing. Icon buttons on touch especially must not let the responder equal the path box.
  • Expose the hit area through a list row, a button fill, or a transparent expansion, so the strokes are not the only tappable pixels.
  • How to check: in a debug overlay, draw the hit area and confirm it is larger than the glyph and clear of neighbours; then tap the "empty" pixels around the drawing on device. If those taps die, the two ledgers are still clipped to the outline.

Related

  • Same group: F6.04.1 How much detail an icon carries sets how small it can go · F6.04.2 Small sizes need their own drawings, not uniform scaling
  • Nearby: E1.07 Button hit targets · F6.08 Visual weight balance of icons
  • Search terms: hit area · hit target · icon size · Fitts

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F6.04.3