You ship a mobile app for field technicians. They close jobs on a phone, often one-handed, sometimes wearing gloves, usually standing in a customer’s driveway. Within a month the support inbox has a new category of ticket: “marked the job complete by mistake.” The “Complete” and “Reopen” buttons sit side by side in the top corner of the screen, each a small icon with a short label. Nothing is wrong with the code. The screen is simply hard to hit.
Fitts law describes this problem. It says the time it takes to reach a target depends on how far away the target is and how big it is. Small, distant targets are slower to hit and easier to miss. Large, nearby targets are fast and forgiving. For product teams, that turns button size, spacing and placement into decisions with a measurable cost, and it gives designers, engineers and product owners a shared way to settle arguments about them without relying on taste.
Where Fitts Law Comes From and What It Covers
Psychologist Paul Fitts published the original research in 1954, measuring how quickly people could tap back and forth between targets of different sizes and distances. The relationship he found has held up across decades of later studies, and it is one of the few quantitative models that interface designers use routinely.
Two phases in every click
Any pointing movement has a fast, rough phase that gets the cursor or finger near the target, followed by a slower correction phase as you fine-tune the landing. A big, close target needs almost no correction. A small, far one needs several small adjustments, and each one adds time and another chance to overshoot. That is why the tiny close icon in the corner of a modal feels fiddly, even though it only takes one click.
What it does not cover
The model describes movement time only: from the moment the hand starts moving to the moment it lands. It says nothing about the time someone spends reading, deciding or hesitating before they move. That distinction helps with diagnosis. If session recordings show users pausing before they move at all, look at labels, hierarchy and the number of options on screen. If they move quickly and then miss, or slow right down as they approach the target, look at size, spacing and position.
The Formula in Plain Terms
The version most often used in interface work is known as the Shannon formulation. It looks more intimidating than it is.
MT = a + b × log2(D / W + 1)
MT is movement time, the thing being predicted. D is the distance from where the pointer starts to the center of the target. W is the width of the target along the line of movement, meaning the clickable area rather than the visible shape. The log2(D / W + 1) part is the index of difficulty, measured in bits, where a higher number means a harder target. The constants a and b are measured for a specific device and group of people.
Use it to compare layouts, not to predict milliseconds
Because a and b change between a mouse, a trackpad and a thumb, the formula is a poor tool for promising how many milliseconds your users will take. It is a very good tool for deciding which of two layouts is easier to hit. Take a “Save” button that sits 800 pixels from where the cursor finishes after the last form field, with a clickable width of 40 pixels.
| Option | Distance (px) | Width (px) | Index of difficulty |
| Current layout | 800 | 40 | about 4.4 bits |
| Double the hit area | 800 | 80 | about 3.5 bits |
| Halve the distance | 400 | 40 | about 3.5 bits |
| Do both | 400 | 80 | about 2.6 bits |
Doubling the width and halving the distance give the same result, because only the ratio between the two matters. That has a practical payoff. If a bigger button would crowd a tidy layout, moving it closer to where the user’s attention already sits gets you the same gain without adding any visual weight.
Fitts Law Fixes for Desktop Interfaces
On desktop, most improvements come from three places: hidden hit area, placement relative to the cursor, and the physical edges of the screen.
Make the hit area bigger than the visible element
The cheapest fix is often invisible. Add padding to text links so the clickable zone extends beyond the words. Make whole table rows clickable instead of only the record name. Let checkbox and radio labels toggle their control. Each change increases W without changing how the page looks. Check the result in your browser’s developer tools by inspecting the element’s box, because the mockup and the built component often disagree.
Put the next action where the cursor already is
Measure distance from where the pointer will be at that moment, not from the top of the page. After a long form, the pointer is at the last field, so the submit button belongs directly below it rather than pinned to a header. Context menus that open at the cursor work well for the same reason: their first options are almost zero distance away. Designers sometimes call the spot under the pointer the prime pixel.
Use edges and corners, with care
On a desktop screen the cursor stops at the edge, so a target that touches the edge behaves as if it were infinitely deep in that direction. People can fling the pointer at it without aiming. Inside a browser the effect is weaker, because many people do not run windows full screen and the page sits inside the browser’s own toolbars, so test at the window sizes your users run.
Give nested menus a forgiving path
Cascading menus that collapse the moment the cursor drifts off a narrow row force people to steer through a tunnel to reach the submenu. A short delay before closing, or a wider hover zone angled toward the submenu, cuts accidental closes.
Use distance as a safety feature
The model also works in reverse. If “Delete” sits right next to “Save,” a slight overshoot causes real damage. Separate destructive actions from primary ones, give them a different visual weight, and add a confirmation or an undo for anything that is hard to reverse. In the field app above, moving “Reopen” into an overflow menu would have done more good than any change to the button labels.
Tap Targets on Mobile: Size, Spacing and Reach
Fingers are less precise than cursors and they cover the thing being pressed, so the penalty for a small target is higher on touch screens.
Know the size guidance
WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), at Level AA, asks for targets of at least 24 by 24 CSS pixels, with exceptions such as smaller targets that have enough space around them. The Level AAA criterion, 2.5.5, sets 44 by 44 CSS pixels. Apple’s Human Interface Guidelines recommend 44 by 44 points for touch controls, and Google’s Material Design guidance uses 48 by 48 density-independent pixels. Treat 24 as a floor and aim for 44 or more on primary actions. You can read the full criteria in the W3C’s WCAG overview, and our guide to the web content accessibility guidelines explains how they apply to product work.
Measure the tap area, not the icon
A 20 pixel icon inside a 44 pixel tappable box meets the guidance. The same icon with no padding does not. Check rendered sizes on real devices, including with larger system text turned on, because text scaling can shrink the space between targets or push them into each other.
Plan for more than one grip
People hold phones one-handed, two-handed, cradled in one palm while pointing with the other hand, or flat on a desk. A layout tuned only for a right thumb fails a lot of them. As a working rule, put frequent primary actions in the lower part of the screen, where most grips reach comfortably, and keep rare or risky actions further away. Large phones push the top corners out of easy reach, so test on both a small and a large device. A mobile-first UX strategy settles these zones early, before content pushes key buttons into awkward corners.
Mobile review checklist
Run these checks on every screen that carries a key action:
- Primary actions sit within easy reach and have a tap area of at least 44 by 44.
- Confirm and cancel have clear space between them, and the destructive one is not where the thumb lands first.
- Checkbox and radio labels are tappable, not only the small control beside them.
- Sticky bars, chat widgets and cookie banners do not cover targets near the screen edge.
- Buttons stay put while images and late-loading content appear.
A button that jumps 50 pixels just as someone taps turns a well-aimed tap into a miss, and no amount of target sizing helps if the target will not stay still.
If you suspect missed taps and wrong clicks are costing you sign-ups or filling your support queue, an M7 UX audit reviews your key flows on real devices, checks targets against WCAG, and shows you which buttons, links and controls to resize or move first.
How to Test Target Size and Placement Changes
A fix that looks right in a mockup still needs evidence from real people on real hardware. You do not need a lab to get it.
Pick the actions that matter most
Choose the two to four actions that carry the most value or the most risk, such as “Add to cart,” “Submit claim” or “Approve payment.” Recruit people who match your users, including some who use larger text or assistive technology, and test on the devices they own, whether that is a trackpad on a laptop or a mid-range Android phone with a cracked screen protector.
Measure speed and accuracy together
Speed on its own misleads. A layout that is faster but causes more wrong taps is worse than a slightly slower one that people hit reliably. For each target, record time to hit, miss rate, wrong-target rate and task completion. Researchers combine speed and accuracy into a single throughput score in bits per second, but for most product teams, before-and-after miss rates and completion rates are enough. Tie the results to the user experience metrics your leadership already watches so the change has a business case.
Use field data to find the next problem
Session recording tools flag rage clicks, dead clicks and repeated taps. Clusters around a small icon, a close button or a link buried in dense text usually point to a target that is too small or too close to a neighbor. A dead click can also mean people expect something to be clickable when it is not, so watch a few recordings first.
Build proven fixes into your components
Once a change works, put it in the component library so every team gets the larger hit area or the safer spacing by default. Minimum target sizes and spacing tokens are easy to encode in design systems for scaling digital products, and doing so stops the same problem coming back with every new feature.
Mistakes Teams Make With Target Sizing
Making every button bigger. Size signals importance. Inflate everything and you lose hierarchy, crowd neighboring controls and increase wrong taps. Give the extra size to the actions that matter and keep secondary ones modest.
Ignoring diminishing returns. Because the formula is logarithmic, enlarging a target that is already comfortable gains very little. Growing a 24 pixel icon to 44 pixels makes a noticeable difference. Growing a full-width button to fill even more of the screen does not.
Measuring distance from the wrong place. Distance should start from where the cursor or thumb is just before the action, which depends on the task. A button that looks central in a static mockup can be a long way from the field the user just finished.
Treating the calculation as a verdict. The index of difficulty ranks options. It does not account for labels, visual contrast, layout shift or a user’s grip, so confirm the winning option with people before rolling it out.
Make the Important Actions the Easy Ones
The field app from the opening did not need new code. It needed a larger gap between “Complete” and “Reopen” and a less prominent home for the action people rarely use. Most target problems are that cheap to fix once someone looks for them, and the fixes add up when they are built into every screen rather than patched one at a time.
At M7, target sizing, spacing and placement are part of how we design and build interfaces, and our engineers implement hit areas exactly as they were designed rather than shrinking them during build. If your product has screens where people keep pressing the wrong thing, talk to our team about finding and fixing them.
Frequently Asked Questions
Is it Fitts law or Fitts’s law?
Both spellings are common. The model is named after Paul Fitts, so “Fitts’s law” is the standard possessive form in academic writing, while “Fitts law” and “Fitts’ law” appear widely in design articles and search queries. They all refer to the same principle.
How is Fitts law different from Hick’s law?
Fitts law covers the physical movement to a target once a person knows where they are going. Hick’s law covers decision time, which grows as the number of choices grows. A slow interaction can suffer from either one, so check whether people hesitate before moving or struggle once they move.
Does Fitts law apply to keyboard and voice interfaces?
Not directly, because there is no pointing movement. That is one reason keyboard shortcuts appeal to power users: they remove travel time completely. For keyboard users, the closest equivalent concern is the number of Tab presses needed to reach a control, which logical focus order keeps low.
Does Fitts law work the same way on touch screens?
The general relationship holds, but touch adds problems a mouse does not have. The finger hides the target as it lands, and accuracy drops sharply once targets are smaller than a fingertip. That is why touch guidance sets minimum sizes in addition to the usual advice about distance.
