Hicks Law

Hick's Law

Hick's Law (more precisely, the Hick-Hyman Law) is the empirical observation that the time required to make a decision among a set of options grows with the logarithm of the number of options. Stated as a formula:

T = b · log₂(n + 1)

Where T is decision time, n is the number of equally likely choices, and b is a constant determined by the cognitive context. The +1 accounts for the time to begin processing the choice set at all. The logarithmic growth is the design-relevant insight: doubling the number of options does not double decision time, but it does add a roughly constant increment each time.

Definition (in our own words)

When a user must select one option from a set, the time and cognitive effort required to make that selection rise as the set grows — but not linearly. The user can scan and pick from a small set quickly; they need progressively more time as the set grows; and beyond a certain size (typically around 7–10 options for a flat list) they switch from scanning to searching, which is a different and slower mode.

Origins and research lineage

• Hick (1952) measured reaction time as a function of the number of stimulus alternatives in a simple keypress task. He found a logarithmic relationship.
• Hyman (1953) extended this with similar results across varied stimulus types, confirming the general law.
• Card, Moran & Newell (1983) in The Psychology of Human-Computer Interaction incorporated Hick's Law into the early model human processor framework that grounded decades of HCI design.
• Modern critiques (e.g., Seow 2005) note that Hick's Law strictly applies to highly practiced, equally-likely choices among visually distinguishable items. Real-world UI choices often violate these conditions — items aren't equally likely, users aren't fully practiced, items have semantic content the user must read. The law is a guide, not a measurement.

The takeaway: more options is more decision cost, the cost grows sub-linearly, and beyond about 7 options the dominant cost shifts from "scan and pick" to "search the list."

Why Hick's Law matters

In product design, every option you put in front of the user is paid for in two currencies: decision time (the user must consider it) and decision fatigue (the user has fewer mental resources for the next decision). On a single screen, the cost of one extra option is small. Across a workflow with many decision points, the costs compound.

Designs that respect Hick's Law feel "easy" — users move through them without stalling. Designs that ignore it feel "complicated" — users hover, deliberate, and sometimes abandon.

When to apply

• Navigation IA. Top-level navigation should typically be 5–7 items. Beyond that, the user can't hold the structure in working memory while scanning.
• Action toolbars. A toolbar with 12 buttons asks a Hick's Law question on every glance. Cap visible actions; tuck the rest into menus or palettes.
• Pickers. Country / timezone / currency / template pickers can have hundreds of items. Don't make the user choose from a flat list of 195 countries — switch to a different interaction (search, recents).
• Wizards. Multi-step flows with many branches at each step compound the law: 4 choices × 4 choices × 4 choices = 64 paths to consider, even if the user only walks one.
• Settings. A settings page with 30 toggles asks the user to evaluate 30 options. Group, default, and progressively disclose.

When NOT to apply (or when to misapply it)

Hick's Law is sometimes invoked to justify removing options that users actually need. Beware of these failure modes:

• The "fewer-is-always-better" trap. Some tasks have irreducible complexity — a tax form genuinely has 50 fields. Hick's Law doesn't say "remove fields"; it says "structure the choices so the user faces fewer at once."
• Assuming Hick's Law applies to text input. Free-text input isn't choosing from a set; it's recall. Hick's Law doesn't apply directly. (Recognition over Recall does — see that principle.)
• Assuming all options are equally weighted. When one option dominates probability (e.g., 80% of users want "Pro" plan), the cost is closer to "scan for the obvious one and click" than to a pure Hick's Law decision. Strong defaults change the equation.
• In expert contexts. Practiced users on familiar tools can navigate large option sets quickly via spatial memory and shortcuts. A power-user IDE can have 200 menu items because experts don't scan them; they fly to known locations.

Strategies for reducing Hick's Law cost

1. Reduce the count

The most direct strategy. Audit the option set: which options are rarely used? Hide them behind "More" / "Advanced" / a command palette. The remaining set should be small enough to scan at a glance.

The 80/20 rule pairs naturally with Hick's Law here: surface the 20% of options that handle 80% of cases; tuck the rest.

2. Group the options

A flat list of 30 items is hard. Three groups of 10 items, each with a heading, is much easier — the user makes a fast group choice (Hick's Law on 3), then a slower within-group choice (Hick's Law on 10).

Flat (Hick's cost: log₂(31) ≈ 4.95)
  Item 1 … Item 30

Grouped (Hick's cost: log₂(4) + log₂(11) ≈ 2 + 3.46 = 5.46)
  Group A
    Item 1 … Item 10
  Group B
    Item 11 … Item 20
  Group C
    Item 21 … Item 30

The arithmetic suggests grouping is worse by raw Hick's Law math. It isn't, in practice, because:

• The user often only needs items in one group (cognitive load is on log₂(4) + log₂(11), not their sum).
• Group headings make the structure recognizable and learnable — repeat visits are faster.
• Visual chunking aids working memory.

The math underestimates how badly humans handle long flat lists.

3. Provide a strong default

If you can pre-select the most likely option, you've cut the choice from N to "1 (the default) or N−1 (everything else)." Most users accept the default, so most users pay almost no decision cost.

This is the single highest-leverage Hick's Law strategy: a good default eliminates the decision for most users.