# Hicks Law > Use this skill whenever a design has many options the user must choose among — menus, navigation, pickers, plan tiers, settings panels, action toolbars, lists of templates, anything that asks "which one?" Trigger when the user is laying out a navigation menu, designing a settings page, picking the structure of a wizard, building a country/timezone/currency picker, designing a pricing table, or reviewing a UI where users hesitate over which control to use. Trigger when there''s debate about "should we add another option?" — Hick''s Law is the principle that costs the option a price. Routes to sub-aspect skills for menus, defaults, and pricing. - Skill: `thedixitjain/hicks-law` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds add thedixitjain/hicks-law` - Raw SKILL.md: https://api.skillmd.com/api/skills/thedixitjain/hicks-law/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: thedixitjain (https://skillmd.com/u/thedixitjain) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/thedixitjain/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. ### 4. Switch interaction mode for very large sets Beyond ~10 options, scanning becomes search. The right interaction is no longer a ` … ``` Decision cost is high (effectively a search, not a scan). Plus, the dropdown UI doesn't allow type-to-find effectively. ```html … ``` The user types "ger," sees Germany, picks it. Hick's Law collapsed to recognition. ### Example 2: navigation ```html ``` User can't decide where to start; eyes sweep, fatigue. ```html ``` Five groups; user picks one in <1 second; sub-nav resolves the within-group choice. ### Example 3: settings ```html
…(27 more)
``` The user is asked to evaluate 30 boolean choices, most of which they don't care about. ```html
Email digest
Push notifications
Advanced (Slack, calendar, custom rules) …(advanced settings, hidden by default)…
``` Now the user faces 3 + 3 = 6 visible choices, both with sensible defaults. Most users accept the defaults. Power users open the disclosure. ### Example 4: a wizard A 4-step wizard with 4 choices at each step has 256 logical paths. The user sees only 4 at a time, so per-step cost is manageable. But cumulative decision fatigue can be high. Mitigations: - Show progress (Stepper) so the user knows the end is in sight. - Default each step's choice based on prior steps when possible. - Allow "I'll come back to this" with a save-and-resume. ## Anti-patterns - **The "kitchen-sink" toolbar.** All possible actions visible at once. Users freeze; the toolbar becomes wallpaper. - **The "expert mode by default" trap.** A new user is shown the same option-rich interface as a power user. They bounce. - **Hidden costs in disclosure.** Putting 20 options inside a "More" disclosure doesn't reduce Hick's Law cost; it just makes the user pay it after a click. Sometimes correct (advanced rarely-used settings), sometimes a procrastination of the real fix. - **Asking before you have to.** A configuration step at sign-up that asks 8 questions before the user has used the product. Defer until the user has context to answer. ## Heuristics 1. **The 7-second test.** Time how long it takes a fresh user to pick the right item from your list. >7 seconds suggests Hick's Law cost is too high; restructure. 2. **The Pareto check.** Look at usage analytics. If 80% of usage is concentrated in 20% of options, surface that 20%; demote the rest. 3. **The "default-acceptance" rate.** Pick a setting where you have a default. What percent of users keep the default? If high, the default is doing its Hick's Law work. If low, your default is wrong (or the question shouldn't have a default). ## Related principles - **`80-20-rule`** — partner principle; identifies *which* options to surface and which to demote. - **`recognition-over-recall`** — the cognitive shift that lets typeahead collapse Hick's Law for very large sets. - **`progressive-disclosure`** — the structural strategy for hiding the long tail. - **`chunking`** — the perceptual basis for why grouped options outperform flat ones. - **`satisficing`** — users pick the first acceptable option; defaults exploit this. - **`flexibility-usability-tradeoff`** (interaction) — adding options gives flexibility *and* costs usability; Hick's Law quantifies the cost. ## Sub-aspect skills - **`hicks-law-menus`** — applying the law to dropdowns, command palettes, navigation menus. - **`hicks-law-defaults`** — using defaults as the primary Hick's Law mitigation. - **`hicks-law-pricing`** — applying the law to plan/tier selection where the choice itself is the conversion event. --- **Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/HDeibler/universal-design-principles/plugins/cognition-and-learnability-principles/skills/hicks-law/SKILL.md`