GlossaryHick's Law

More choices don't just confuse users — they slow them down in ways you can measure

Hick's Law describes how the time it takes to make a decision grows with the number of available options. In product design, it explains why choice overload quietly kills conversion rates and slows down users who should be moving fast.

What Hick's Law Says (and What It Doesn't)

Hick's Law states that the time it takes to make a decision increases logarithmically with the number of available options. Named after British psychologist William Edmund Hick, it was formalised in 1952 following experiments that measured reaction time against stimulus count.

The logarithmic part matters — and is often misquoted. It doesn't mean every new option adds equal friction. The tenth option costs less than the second. That said, in real product contexts, users aren't in controlled lab conditions. Cognitive fatigue, distractions, and unclear option labelling mean the practical cost of each added choice is usually higher than the theory predicts.

What Hick's Law is not: a mandate for minimalism. It's a lens for evaluating friction at decision points — not a rule that demands every interface shrink to three choices.

Where It Shows Up in Product Design

The most obvious application is navigation — primary menus with too many items, settings screens with unlabelled sections, feature lists that force users to hunt. But the more costly version appears in conversion flows.

  • Pricing pages with too many tiers slow selection and push users toward abandonment rather than commitment
  • Onboarding setup flows that front-load preference choices kill Onboarding UX before users ever see the product's value
  • Notification preferences — especially in B2B tools — often list 30+ toggles, most of which get ignored, leaving no preferences set at all
  • Filter panels in dashboards and analytics tools are classic offenders: the more options available, the less anyone uses them

Each of these is a decision point. Hick's Law is most relevant wherever a user has to stop, evaluate, and choose.

When Fewer Choices Is the Wrong Instinct

The impulse to reduce options can create its own problems. In Dashboard Design, a stripped-back view might feel clean but fail the power users who need granular control. In a Design System, limiting component variants too aggressively pushes engineers to work around the system.

The right application of Hick's Law is about sequencing decisions, not eliminating them:

  1. Progressive disclosure — show fewer options initially, surface more as context warrants. This isn't hiding functionality; it's about timing.
  2. Smart defaults — pre-select the most common option so users don't have to engage actively unless they want to.
  3. Grouping — related choices bundled under a clear label reduce perceived complexity without reducing actual functionality. The logarithmic curve effectively resets within each group.

Hick's Law vs Fitts's Law

These two principles are often taught together and sometimes confused.

[Fittss Law](/glossary/fittss-law) is about the physical cost of reaching a target — how far away it is and how large. It governs tap target sizing, button placement, and cursor travel. It's primarily a spatial problem.

Hick's Law is about the cognitive cost of deciding among options. It governs menus, choices, form fields, and decision flows. It's a mental load problem.

They often intersect. A navigation menu that's physically easy to reach can still be cognitively expensive if it has fourteen items with ambiguous labels. Strong interaction design addresses both dimensions — not just one.

Applying It Without Over-Simplifying

When evaluating a screen or flow through the lens of Hick's Law, the question isn't "how few options can we show?" It's "which decisions genuinely need to happen here, and which can be deferred, defaulted, or automated?"

If you're running a UX Audit, decision points are one of the highest-signal areas to examine. Count the choices on each screen. Ask whether each one is load-bearing — whether the user actually needs to make that call at that moment, or whether a smart default would serve them just as well.

The goal isn't fewer features. It's less unnecessary cognitive work at every step.