Skip to content
Motif
Psychology & conversionLesson 1 of 3Beginner13 min

Hick's Law

Hick's Law: the time to decide grows with the log of the number of choices. Fewer, well-grouped options mean faster decisions — but the cost is logarithmic.

Kept on this device only.

In one line: the more options you put in front of someone, the longer they take to choose — but the cost climbs with the logarithm of the count, so the second option hurts far more than the twelfth.

What it is

Hick's Law (sometimes the Hick–Hyman Law) says the time to make a decision rises with the number of choices on offer. The classic form is:

T = b · log₂(n + 1)

where T is the predicted decision time, n is the number of equally-likely options, and b is an empirically measured constant (in seconds) that captures how fast a given person processes a given interface. The + 1 accounts for the choice of whether to respond at all.

The shape of the curve matters more than the exact numbers: because it's a logarithm, doubling the options does not double the time. Going from 2 choices to 4 costs about the same increment as going from 4 to 8.

Why it matters

Every menu, settings page, pricing table, navigation bar, and onboarding step is a decision you're asking the user to make. Hick's Law is why a bloated nav with twenty top-level links feels slower to use than a tidy six — even when the answer is "obviously" in there somewhere.

The practical move is not "always have fewer features." A capable product can still feel fast if you manage perceived choice: group related options, reveal advanced settings only when asked, and pick sensible defaults so most people never have to choose at all. Fewer visible choices ≠ a less capable tool — it's about how much the user has to weigh at the moment of decision.

See it

Live demo
Tweak it3
5
0.15
Add options and watch the predicted decision time climb — but with diminishing pain per item.

Drag the options control up and watch the predicted time climb — but notice the climb flattens. Adding the third option visibly bumps the number; adding the twelfth barely moves it. That diminishing pain per item is the logarithm doing its work.

How it works

Start from the formula, T = b · log₂(n + 1). The log₂ is the key term: each time you double the number of options, you add one "bit" of decision, and each bit costs the same fixed slice of time b. So the marginal cost of one more option keeps shrinking as the list grows — the curve is concave, not a straight line.

That single fact drives the design tactics:

  • Grouping / chunking. Splitting one long list of 20 into four labelled groups of 5 lets the user first pick a group (a small decision) and then an item within it (another small decision). Two cheap log-curve decisions beat one expensive one over the full set.
  • Progressive disclosure. Hide advanced or rarely-used options behind a "More" affordance so the initial decision set is small. The full power is still there; it just isn't on the critical path.
  • Smart defaults. The fastest decision is the one the user doesn't have to make. A good default collapses n effective choices to roughly one for the common case.

Build it

The prediction is a one-line pure function — pick b by timing real users on your actual interface rather than copying a textbook constant.

TypeScript
hickReactionTime.ts — predicted decision time in seconds
/**
 * Predict decision time for n equally-likely choices.
 * b is the per-bit cost in seconds; calibrate it against your own
 * interface (e.g. ~0.15 for a quick on-screen menu, higher for
 * dense or unfamiliar UIs). Garbage b in, garbage seconds out.
 */
export function hickReactionTime(n: number, b: number): number {
  return b * Math.log2(n + 1);
}

Make it yours

Use the controls beside the demo above to change number of options, time per bit, and group into 2 categories — each change updates the example live.

Experiment in the playground
  • Push options from 2 to 4, then from 10 to 12, and compare how much the predicted time moves each step — the second jump is far smaller. That asymmetry is the whole lesson.
  • Imagine splitting a 12-item list into three groups of 4: each decision now runs log₂(4 + 1) instead of log₂(12 + 1). Sketch what that does to the felt speed.
  • Try a much larger b in the hickReactionTime function and notice the curve keeps its shape but scales up — b sets the height, the logarithm sets the bend.

Reproduce it with an LLM

Reproduce it with an LLM

You are a product designer who applies Hick's Law (decision time rises with the log of the number of choices). I have a screen that overwhelms users — 'a settings page with 24 options shown as one flat list'. Redesign the information architecture to reduce perceived choice without removing capability: group related options into a few labelled sections, surface the 3-4 most common actions first, defer the rest behind progressive disclosure, and pick smart defaults so most users choose nothing at all. Explain each change in terms of Hick's Law, and flag any place where MORE visible choice is actually better. Return a restructured outline plus a short rationale.

Run with your key

Pitfalls & accessibility

  • A search or type-ahead can beat the menu entirely: it converts an O(log n) scan into a direct jump, which is why a well-placed command palette feels instant even over a huge command set.

Further reading