Fitts's Law and Why Target Size Matters

Fitts's law is one of the few ideas in interface design that you can write down as an equation and then watch play out in a usability session. It says that the time it takes to move a pointer, a finger or a stylus onto a target depends on two things: how far away the target is and how big it is. Near and large is fast. Far and small is slow and error-prone. Understanding Fitts's law and pointer targets is what separates a screen that feels effortless from one that makes people squint, hover, miss and try again.

It matters to anyone who ships an interface people use for work or money: product owners watching a checkout drop off on mobile, operations leads whose staff tap through the same form two hundred times a day, and designers who have to defend a 48-pixel button in a review where someone wants it "a bit more elegant." It also matters to accessibility compliance, because the Web Content Accessibility Guidelines now set a minimum target size, and "the icon looked fine on my monitor" is no longer a defense.

Rather than restate the theory in the abstract, this guide follows one project from brief to delivery. The project is an illustrative example: a composite built to show how the decisions get made, not a real client engagement, and every number in it is an assumption chosen to be realistic. Along the way we explain each decision, the traps we avoided, and how you can apply the same reasoning to your own product.

The Illustrative Project: A Field-Service App That Felt "Fiddly"

Imagine a regional appliance-repair company with about 60 technicians. Each technician uses a web app on a company-issued phone to open the day's jobs, record parts used, capture a customer signature and close the job. The app was originally designed on desktop monitors by a small internal team, then made "responsive" late in the process. It works. Nothing is technically broken. But the operations manager's brief contained one sentence that is common in these projects: "The techs say the app is fiddly and they hate the job-close screen."

"Fiddly" is a useful complaint because it usually points at target acquisition problems rather than information architecture problems. People rarely call a confusing navigation structure fiddly; they call it confusing. Fiddly means their hands are doing extra work: missed taps, accidental taps, zooming, repositioning the phone, switching from thumb to index finger. That is Fitts's law territory.

What the brief actually asked for

The written brief asked for three outcomes: reduce the time it takes to close a job, reduce errors on the parts-used list (wrong quantities, wrong items), and make the app pass an accessibility review the company's largest commercial customer had started requiring from its vendors. There was no budget for a native rebuild, so the work had to stay in the existing web app. If you are weighing that choice yourself, our comparison of choosing between a web app and a native app covers the trade-offs; here, the constraint was fixed and the design had to work inside a mobile browser.

The working context that shaped every decision

Technicians use the app standing up, often one-handed, sometimes wearing work gloves, frequently in a basement or a garage with poor light. They hold a toolbox, a part or a flashlight in the other hand. That context matters more than any guideline, because Fitts's law describes the motor task, and the motor task in a basement with one thumb is very different from the motor task at a desk with a mouse.

How Fitts's Law Works, in Terms You Can Design With

Paul Fitts described the relationship in the 1950s while studying how quickly people could make rapid aimed movements. The version most often used in human-computer interaction today is the Shannon formulation: movement time equals a plus b times the base-2 logarithm of (distance divided by width, plus one). The constants a and b depend on the device and the person; the part inside the logarithm is called the index of difficulty, measured in bits. The Interaction Design Foundation's explanation of Fitts's law is a good plain-language reference if you want the history and the derivation.

You do not need to calculate anything to use the law well, but three properties of the equation should shape your instincts:

• It is a ratio. Difficulty depends on distance relative to size. A small target close to the pointer can be as easy as a large target far away. Doubling the size of a target has the same effect on difficulty as halving the distance to it.
• It is logarithmic. Going from tiny to modest makes a big difference; going from large to enormous makes very little. A 16-pixel icon enlarged to 32 pixels is a meaningful improvement. A 64-pixel button enlarged to 128 pixels mostly wastes space.
• Width means width along the direction of travel. A wide, short button is easy to hit when approached horizontally and harder when approached vertically. Menu items in a vertical list are approached vertically, so their height is what matters most.

Why screen edges are valuable

With a mouse or trackpad, the cursor stops at the edge of the screen. A target placed flush against an edge therefore has effectively unlimited depth in the direction of travel: the user can throw the pointer at it without slowing down and cannot overshoot. Corners are even better because they stop the cursor in two directions. This is why desktop operating systems put menus, docks and start buttons against edges, and why a control that sits a few pixels away from the edge, with a dead gap between it and the boundary, throws that advantage away.

The edge advantage does not transfer cleanly to touch. A finger does not stop at the edge of the glass; it simply lands wherever it lands. On phones, edges are valuable for a different reason: they are predictable, persistent locations that thumbs learn. But the far top corners of a large phone are among the hardest places to reach one-handed. So "use edges" means "use the edges the thumb can reach" on touch, and "use the edges the cursor stops at" on desktop.

Why fingers need bigger targets than cursors

A mouse cursor has a single-pixel hotspot and the user can see it before clicking. A fingertip covers a patch of screen far larger than a typical icon, hides the target at the moment of contact, and lands with some scatter around where the person intended. Touch targets therefore need to be larger than pointer targets, and they need space around them so that a slightly off-center tap does not land on a neighbor. For platform-specific sizing detail, our companion guide on touch target sizes that actually work goes deeper than we can here.

Measuring the Baseline Before Touching the Design

The first real decision in the project was to measure before designing. It is tempting to open the design file, spot the tiny icons and start enlarging things. The problem is that without a baseline you cannot tell the operations manager whether the redesign worked, and you cannot tell which fixes mattered.

The target-size audit

We listed every interactive element on the four screens technicians use most and recorded, for each one, its rendered size in CSS pixels at the phone viewport, the gap to its nearest neighboring target, and how often it is used in a typical job. Measuring in CSS pixels rather than device pixels matters: WCAG measures target size in CSS pixels, and a high-density phone screen will show three or four device pixels for every CSS pixel.

In our illustrative audit, the findings were typical of a desktop-first app squeezed onto a phone:

• The quantity steppers on the parts list (the minus and plus buttons) rendered at 18 by 18 CSS pixels, with 4 pixels between them.
• The "remove part" icon was a 16-pixel trash can sitting 6 pixels to the right of the plus button, which is how quantities kept being deleted instead of increased.
• The "Close job" button was a full-width button, which is good, but it sat at the top of the screen in the header, the farthest possible point from a thumb holding the phone at the bottom.
• The modal close icon on the signature screen was 20 by 20 pixels in the top-right corner.

Timed task sessions

We then ran short timed sessions with eight technicians on the existing app, each completing the same scripted job-close task three times. Eight is not a statistically robust sample for precise timing claims, and we did not treat it as one; it is enough to see where people struggle and to get a rough baseline to compare against later. How many participants you need depends on what decision the numbers will support, which is covered in our guide to choosing usability test sample sizes. For measuring the tasks themselves, we followed the approach in measuring task success and time on task properly: a clear start and end signal, the median rather than the mean, and errors recorded separately from time.

What the Baseline Revealed About Distance, Size and Errors

The illustrative baseline numbers told a clear story. The median time to close a job, from opening the job screen to seeing the confirmation, was 94 seconds. Across 24 attempts, we logged 31 mis-taps, meaning a tap that landed on the wrong control or on nothing at all, and 5 attempts where a part was removed by accident when the technician meant to increase its quantity.

When we mapped the mis-taps to elements, nearly all of them clustered around three areas: the quantity steppers, the trash icon beside them, and the signature modal's close icon. Those are exactly the elements the audit flagged as small and tightly packed. The long overall time, on the other hand, was driven less by mis-taps than by distance: technicians repeatedly shifted their grip to reach the "Close job" button in the header, and several switched to a two-handed hold, which meant putting down whatever they were carrying.

This split is worth noticing because it points to two different fixes. Mis-taps are mostly a size-and-spacing problem. Slowness is mostly a distance problem. Fitts's law covers both, but the design responses differ, and a team that only enlarges icons will fix the errors while leaving the slowness intact.

Reading behavior, not just numbers

The ride-along observations added detail the timings could not. Technicians had developed workarounds: some zoomed the browser before editing quantities; one typed quantities into a search field instead of using the steppers; two left the signature modal open and navigated away with the browser's back button because the close icon was too hard to hit with a gloved finger. Workarounds like these are strong evidence of a target problem, and they are also a warning that fixing the targets may change behavior in ways you should plan for.

Redesigning the Job-Close Screen Around the Thumb

With the baseline in hand, the redesign started with distance, because that was where most of the time went. The principle is simple: put the primary action where the hand already is. On a phone held in one hand, that is the lower part of the screen.

Moving the primary action to the bottom edge

We moved "Close job" from the header into a sticky footer bar that stays pinned to the bottom of the viewport. The button spans the full width of the screen minus a 16-pixel gutter on each side, and is 56 CSS pixels tall. Full width means the button's width along the direction of a typical thumb movement is as large as the screen allows. The height was chosen to be comfortably above platform minimums while leaving room for the parts list above it.

We also added safe-area padding below the button so that on phones with a home indicator, the button does not sit on top of the system gesture area. A primary action that competes with the operating system's swipe-to-go-home gesture creates a different kind of mis-tap, one that throws the user out of the app entirely.

Deciding what counts as the primary action

Not everything can be large and near the thumb. We ranked every action on the screen by frequency and consequence. "Close job" is used once per job but is the whole point of the screen. Quantity changes are used several times per job. "Add part" is used a few times per job. "Report a problem" is used rarely. Frequency and importance together decided position and size: the most frequent and most important actions got the thumb zone and the largest targets, while rare actions moved into an overflow menu at the top, where the extra reach is an acceptable cost for something used once a month.

The choice of control type also mattered. "Close job" performs an action, so it is a button; "View job history" navigates, so it became a link styled as such. Getting that distinction right affects both semantics and expectations, as our guide to buttons versus links explains.

Applying WCAG 2.2 Target Size Rules to Real Controls

The accessibility requirement from the commercial customer gave the project a hard floor. WCAG 2.2 introduced Success Criterion 2.5.8, Target Size (Minimum), at Level AA. It requires pointer targets to be at least 24 by 24 CSS pixels, with specific exceptions. The W3C Web Accessibility Initiative's guidance on understanding target size explains the intent and the exceptions in detail, and it is worth reading in full before an audit.

How the spacing exception works

The criterion does not simply ban small targets. A target smaller than 24 by 24 pixels can still pass if it has enough spacing: if you draw a 24-pixel-diameter circle centered on the target's bounding box, that circle must not intersect another target or the circle drawn around another undersized target. In practice, this means an 18-pixel icon can pass if it is isolated, but two 18-pixel icons 4 pixels apart cannot. There are further exceptions for targets that have an equivalent control elsewhere on the page that meets the size, targets inline in a sentence of text, targets whose size is set by the browser rather than the author, and cases where a particular presentation is essential or legally required.

The minimum is a floor, not a target

Passing 2.5.8 at 24 pixels is necessary for this project, but it is not sufficient for gloved thumbs. WCAG also has an older Level AAA criterion, 2.5.5 Target Size (Enhanced), that asks for 44 by 44 CSS pixels, and the major mobile platform guidelines recommend touch targets in a similar range. We set the project's internal standard at 44 by 44 CSS pixels for any control a technician uses during a job, and treated 24 pixels with correct spacing as the absolute minimum for rarely used, secondary controls such as a help icon in the header.

Hit areas versus visible size

Target size in WCAG refers to the area that responds to the pointer, not the visible icon. That gives designers an important tool: an icon can stay visually compact while its tappable area extends beyond its drawn edges through padding. The help icon in the table above is drawn at 24 pixels but responds across a 44-pixel square. The caveat is that invisible hit areas must not overlap each other, and users cannot see them, so they work best for isolated controls. For controls that sit side by side, making the visible target match the hit area is more honest and avoids the "I tapped the one next to it" problem.

Spacing, Grouping and the Parts List Problem

The parts list was where most errors happened, and it needed more than bigger buttons. Each row showed a part name, a quantity, a minus button, a plus button and a trash icon, all on one line at 375 pixels wide. Making every one of those targets 48 pixels would have left almost no room for the part name.

Separating constructive and destructive controls

The most important change was moving the destructive action away from the constructive ones. Placing "remove" 6 pixels from "increase" meant that a small overshoot to the right turned a routine edit into a deletion. Fitts's law tells you that an error-prone neighbor is effectively part of your target's landing zone. We removed the trash icon from the row entirely. Removal now happens by setting the quantity to zero, with a clear prompt, or through a swipe-left action that reveals a large "Remove" button, or through the row's overflow menu. Three routes may sound like a lot, but each suits a different habit, and none of them sits next to the plus button.

Protecting against the errors that remain

Even with larger targets, a technician in a hurry will occasionally remove the wrong part. Instead of adding a confirmation dialog, which adds another target to hit and another interruption for every legitimate removal, we added an undo toast that stays for several seconds after a removal. For low-stakes, reversible actions, undo is usually better than confirmation, a trade-off explored in our guide to confirmation dialogs and undo. The undo button itself is 44 pixels tall and sits just above the sticky footer, inside the thumb zone.

Choosing the right input for quantities

Steppers are good for small adjustments near a default; they are slow for large changes. Most parts are used in quantities of one to three, so steppers stayed, but tapping the quantity number itself now opens a numeric keypad for the occasional box of 50 screws. That gives a single large target for the common case and a fast route for the uncommon one. Choosing between steppers, dropdowns and other selection controls follows one rule: match the control to the range and frequency of values.

Testing the Prototype With Gloved Hands and One Thumb

We built the redesign as a coded prototype in the browser rather than as clickable mockups in a design tool. That decision was driven by Fitts's law itself: target acquisition depends on exact rendered sizes, real touch behavior and real scroll physics, and design-tool prototypes on phones often render at slightly different scales and with different touch handling than the production browser. When the thing you are testing is motor performance, the test needs to use the real motor surface.

The test plan

We recruited eight technicians again, including four who had not taken part in the baseline, so we could see whether the improvement held for people without prior exposure to the test script. Recruiting from a working field team takes coordination with dispatch so that nobody loses billable time; we booked short slots at the start of shifts, before the first dispatch. Each participant completed the same scripted job-close task three times, standing, holding a part in the non-dominant hand, and wearing gloves if they normally wore them for that type of job.

What we looked for beyond speed

We recorded time and mis-taps as before, but we also watched grip changes, zooming and any return of the old workarounds. A redesign that is faster on the stopwatch but still requires two hands has not solved the brief. We also checked the first tap on each screen: where did people reach first when asked to close the job? First-click behavior is a strong predictor of whether a layout matches expectations, and our guide to first-click testing shows how to run it on its own when you want a quick signal before a full session.

What changed after testing

Testing surfaced two issues. First, the sticky footer's "Close job" button was so easy to hit that two participants tapped it before capturing the customer signature. The fix was not to make it smaller; it was to show the button in a disabled-looking state with the label "Capture signature to close" until the signature existed, and to put the signature step directly above it. Second, the swipe-to-remove gesture was not discovered by anyone without a hint. We kept it for experienced users but made the overflow menu the documented route, since a gesture that nobody finds is not a target at all.

The Results, Read Carefully

In the illustrative comparison after the pilot rollout, the median job-close time dropped from 94 seconds to 61 seconds. Mis-taps fell from 31 across 24 attempts to 7 across 24 attempts, and there were no accidental part removals. The zooming and back-button workarounds disappeared from observation. Those are the kinds of changes you would expect when a flow moves its primary action into reach and brings its most-used controls from 18 pixels to 48, but they are example figures for this composite project, not a benchmark for yours.

Reading results like these responsibly means separating what the design changed from what else changed. Some of the speed improvement came from removing steps, not only from larger targets: the signature step moved next to the close button, eliminating a scroll. Some came from familiarity, since four participants had seen the task before. A good report attributes improvements cautiously, notes the small sample, and recommends continued measurement after full release rather than claiming a precise percentage improvement from eight people.

Worked example: estimating the time effect of moving one button

If you want to reason about a change before testing it, the Fitts equation lets you compare options on a relative basis. Suppose the thumb starts near the bottom of the screen and the "Close job" button in the header is about 600 CSS pixels away, with an effective height of 36 pixels along the direction of travel. The index of difficulty is log2(600/36 + 1), which is about log2(17.7), or roughly 4.1 bits. Move the button to a footer about 120 pixels from the resting thumb position and make it 56 pixels tall, and the index becomes log2(120/56 + 1), about log2(3.1), or roughly 1.7 bits. With any plausible device constant, the second layout is substantially faster to acquire. You cannot turn that into seconds without measuring a and b for your users and devices, and for thumbs the standard model is only an approximation, but the comparison tells you which option to prototype first and roughly how large the difference should feel.

The short version: small targets cause errors, and distant targets cost time. Fix the size and spacing to stop the mis-taps, and fix the placement to stop the reaching.

Handoff and Design QA: Keeping Target Sizes Intact in Production

Many good target-size decisions die during implementation. A developer uses the icon's intrinsic size instead of the specified hit area, a component library's default button height overrides the design, or a later feature squeezes a new icon between two existing ones. The handoff for this project therefore treated target size as a specification, not a visual suggestion.

Encoding the rules in the design system

We added two tokens to the team's component library: a minimum interactive size of 44 pixels for any in-job control, and a minimum gap of 8 pixels between adjacent interactive targets. Icon buttons were rebuilt as a single component that always renders a 44-pixel hit area around a 24-pixel glyph, so nobody can accidentally ship a bare 16-pixel icon as a button. When rules live in components, they survive new features and new developers.

Checking before release

Before release, the QA pass included a target-size check at 320 and 375 pixel viewport widths, text zoom at 200 percent to confirm targets did not overlap when labels grew, and a quick keyboard and screen-reader pass to confirm the enlarged hit areas did not break focus order. The checklist approach we use is described in our guide to design QA before release; target size is one of the items most often missed because it looks fine in a static screenshot.

The underlying decision was to put the size and spacing rules into components rather than into a document. A written guideline is advice; a button component that cannot render smaller than 44 pixels is a guarantee. This also made the accessibility evidence for the commercial customer far easier to produce.

Applying the Same Reasoning to Your Own Interface

The project above is a phone-first field app, but the same reasoning applies to desktop dashboards, e-commerce checkouts, kiosks and in-car screens. The details change with the input device; the logic does not. Here is how to translate it.

On desktop and laptop screens

Use the edges and corners for persistent controls such as global navigation, and let them touch the edge rather than floating a few pixels in. Put contextual actions near where the work is happening: an inline edit button next to the field being edited is faster than a toolbar across the screen. Right-click and hover menus open at the cursor, which makes their first items effectively zero-distance targets, so put the most common command first. And avoid tiny close buttons on dialogs and notifications; a 12-pixel "x" in a corner that is not flush with the screen edge gets none of the edge benefit.

On phones and tablets

Design for the thumb. Put primary and frequent actions in the lower half; put rare or destructive actions where they take a deliberate reach. Meet at least 24 CSS pixels with correct spacing for compliance, and aim for around 44 to 48 for anything used often. On tablets, remember that people often hold the device by its sides, so controls near the left and right edges at mid-height can be more reachable than a bottom-center bar.

In forms

Forms are full of small targets: checkboxes, radio buttons, date pickers, inline help icons. Make the whole label clickable for checkboxes and radio buttons, which enlarges the target without changing the visual design. Keep the submit button near the last field instead of at a fixed corner far away. For longer forms, the placement of "Next" and "Back" buttons follows the same distance logic; keep them together at the bottom, with the forward action on the side of the dominant thumb.

Common mistakes to look for in a quick audit

• Close buttons on modals and banners that are smaller than 24 pixels and tucked into a corner that is not a screen edge.
• Important actions placed far from the cursor's natural path, such as a "Save" button at the top of a long form the user has just scrolled to the bottom of.
• Adjacent icon buttons with no spacing, especially where one is destructive.
• Pagination links and filter chips rendered at text size on mobile.
• Desktop-sized targets carried unchanged into the mobile layout.

When to Bring in Outside Help With Target Sizing

Many teams can fix obvious target-size problems themselves once they know what to look for: audit sizes and gaps, enlarge hit areas, move primary actions within reach. It makes sense to bring in help when an interface feels fiddly on touch devices and the fixes are not obvious, when enlarging targets would break a dense layout and the information architecture needs rethinking, when you need defensible measurement to justify the change, or when an accessibility requirement from a customer or regulator puts a deadline on it.

An experienced team brings three things in that situation: a structured audit that finds every undersized and crowded target rather than the obvious ones, testing in the real context of use, and component-level fixes that keep the problem from coming back. If you are evaluating partners, our guide to working with external design teams covers how to scope that kind of engagement, and our UI and UX design service includes target-size and touch-ergonomics audits as part of interface reviews.

Questions to ask before you start

• Which tasks are performed most often, and on which devices and input methods?
• Where do errors cluster today, and can you log or observe them?
• Is there a compliance requirement, and at which WCAG level?
• Can size and spacing rules be enforced in shared components, or will each screen need individual fixes?

Fitts's law is old, simple and still underused. Most interfaces do not need a new visual style to feel better; they need their most important controls to be bigger, closer and better separated from their neighbors. Measure where the hands struggle, fix size and spacing for errors, fix placement for speed, and lock the rules into your components so the improvement lasts.

Where this comes from

• Interaction Design Foundation — Fitts's law
• W3C Web Accessibility Initiative — Understanding Success Criterion 2.5.8 Target Size (Minimum)

The figures and practices above come from the sources listed.

Working on something like this?

We take on UI & UX Design work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• Onboarding Checklists and Progress, Done Properly
• Saving Progress in Long Forms: What Actually Works