Fitts’s law

In short

Pressing a small target far away takes longer than a large one nearby. Fitts’s law turns this intuition into a measurable formula.

The pointer can be the mouse cursor, but also a finger or a hand. That is why NN/g explains the law for desktop and touch together.

Measure it yourself in the game below. First try the small, far target a few times, then the large, near one.

Live demo: press the target

Press Start. An orange target appears in the area; press it as fast as you can. If you press next to it, that counts as a miss.

Click speed game

This game needs JavaScript. If it’s off, the text below explains the same idea with the formula and examples.

The time measured runs from pressing Start to pressing the target. Difficulty is calculated with MacKenzie’s Shannon formula in pixels. This isn’t a controlled experiment, so make a few attempts and look at the average. With the keyboard, after Start you Tab to the target and press Enter. Then distance hardly changes the time at all.

With the small, far target, your time is very likely longer, and your misses go up. According to the note on Laws of UX, moving quickly to a small target leads to more errors. The faster you go, the more accuracy you lose.

The formula: what is measured?

On this page and in the demo, I use the Shannon formula that MacKenzie advocated in 1992.

MT = a + b × log₂(D / W + 1)

• MT: movement time.
• D: distance to the target. MacKenzie calls it amplitude (A).
• W: width of the target. MacKenzie discusses how, for rectangular targets, this width changes with the direction of approach.
• a and b: empirically determined constants. According to NN/g, they depend on the type of pointing device.

The part log₂(D / W + 1) is called the index of difficulty (ID). Its unit is bits. The “Difficulty” box in the demo shows this value.

NN/g describes the movement in two parts. First comes a fast, rough jump toward the target, mostly affected by distance. Then follows a slow correction for accuracy. The smaller the target, the longer this second part takes.

Origin: Paul Fitts, 1954

The source of the law is Paul M. Fitts’s 1954 paper “The information capacity of the human motor system in controlling the amplitude of movement”. It appeared in the Journal of Experimental Psychology, volume 47, pages 381 to 391.

According to MacKenzie, Fitts ran four experiments. In two, participants tapped back and forth between two targets with a stylus, once with a light stylus and once with a heavy one. The other two were disc transfer and pin transfer tasks.

In Fitts’s own formula, difficulty was log₂(2D / W). MacKenzie writes that the factor of 2 was an arbitrary adjustment by Fitts. Fitts had derived the formula by analogy with Theorem 17 in Shannon’s information theory.

In 1992, in the journal Human-Computer Interaction, MacKenzie advocated the Shannon formula. One of his reasons: in the old formula, difficulty can turn negative when the distance is very short relative to the target. The Shannon formula prevents this, and according to MacKenzie it also fits the data slightly better.

The law doesn’t apply only to the mouse. MacKenzie writes that it also gives good results for different limbs and muscle groups. The abstract of his paper names these devices: mouse, trackball, joystick, touchpad, helmet-mounted sight and eye tracker.

Applying it in the interface: examples

The examples are typical and don’t target any particular app. For each, I ask two questions: how big is the target, and how far is the user’s pointer from it?

1. The “Place order” button at checkout

In an online store, the last thing the user enters is their card’s security code. If the confirm button sits in the summary box at the very top of the page, they have to go back up the whole form.

NN/g’s recommendation is clear: the submit button belongs next to the last form field. The article also criticises mobile designs that put the button at the very top of the page.

Labelled buttons win here too. According to NN/g, icon and label together form a larger target, as long as the whole area is clickable. If the cart has a trash icon next to “Remove” but only the drawing is clickable, that condition is broken.

2. The bottom menu of a mobile app

In a banking app, frequent tasks such as “Send money” sit in the tab bar at the bottom. From Fitts’s point of view, the bar’s strength comes from being close to the thumb. Being at the edge of the screen brings no extra gain on touch.

If the tabs are too close together, a different risk arises. NN/g writes that crowded targets lead to overshooting and wrong selections, especially when they are small.

Distance matters for context menus too. According to NN/g, a submenu that opens far from the tapped element wastes movement time. The options should appear next to the label that opens them.

3. Screen edges and corners

With a mouse, the screen edge acts like a wall. The cursor stops at the edge and can’t go past the target. NN/g therefore calls targets along the edge “infinite targets”. The menu bar at the top in macOS and the taskbar at the bottom in Windows are there for this reason.

NN/g also notes that the Start button in Windows sat in the bottom-left corner at least until Windows 8. On a web page in a browser, I hardly expect this advantage. The edge of the page usually isn’t the edge of the screen.

On a touchscreen, this flips. Drawing on a study by Avrahami, NN/g reports that targets at the edge take longer on touch. The finger doesn’t stop at the edge like a cursor; it can go past it.

Limits and misconceptions

It doesn’t give pixel sizes. The law compares two designs; it doesn’t say “make it this big”. The NN/g article gives no number either. For the web, success criterion 2.5.8 of WCAG 2.2 sets the minimum: at Level AA, targets are at least 24 × 24 CSS pixels. For smaller targets there is a spacing exception and a few other exceptions.

Enlarging has a ceiling. Make every button bigger, and the screen gets cramped and the targets move closer together. According to NN/g, crowded targets increase wrong selections.

Invisible padding is half a solution. Keeping the clickable area larger than the visible icon helps. But NN/g warns: if users don’t notice the padding, they aim at the visible drawing and slow down anyway.

The edge rule doesn’t apply to touch. With a mouse, the edge is an advantage; on a phone it isn’t. Copying the desktop rule into mobile design is therefore misleading.

It doesn’t cover keyboard and screen reader users. The law measures pointing. For someone navigating with the keyboard, the cost isn’t pixels but how many times they press Tab to reach the target. You see this if you play the demo with the keyboard.

It isn’t the only explanation. If a button gets pressed quickly, that may be down to its position or its name, not just its size. Whether users know where to look is a separate topic that Fitts doesn’t measure.

My note

The most common Fitts mistake in my audits: the primary button stands apart from the form. The user fills in the last field and looks for the button somewhere else on the page. Putting the button right below the last field is usually a one-line change.

In second place are small icon buttons in text. Icons such as edit and delete are small drawings, and often the clickable area is just the drawing itself. Without enlarging the icon, I extend that area to at least the size criterion 2.5.8 requires.

I don’t use the law as a design rule on its own. When I review a screen, it makes me ask two questions. Is what gets pressed most often the easiest to press? Are dangerous buttons too close to frequently pressed ones?

If you want these checks done on your product, the UX Audit also covers target size and layout. I describe the method in the UX audit guide.

Related pages

Which size to choose on phones, with the Apple, Android and WCAG measurements, is covered in the touch target pattern and the mobile app design guide.

Fitts tells you where to look for a problem. To weigh how much a problem hurts users, Nielsen’s 10 usability heuristics give a good framework. The other laws are in the list of laws of UX.

For the wider context of the term, read the definition of usability.