Hick's Law states that decision time increases logarithmically with the number and complexity of choices presented at once. In products, this means every extra menu item, settings toggle, or pricing tier adds real cognitive tax—even if the user never selects it. The fix isn't removing capability; it's hiding it until it's needed.
Quick Answer: More options almost always mean slower, more anxious decisions, not more satisfied users. Reduce what's visible by default, group the rest into clear categories, and reveal complexity only when someone asks for it.
What Hick's Law Actually Says About Product Design
Hick's Law, formalized by psychologists William Edmund Hick and Ray Hyman in the 1950s, predicts that reaction time to choose among n options grows roughly with log2(n+1). Double the choices and decision time doesn't double—but it does climb, and the climb is steeper than most product teams assume when they add "just one more option."
The original experiments used simple stimulus-response tasks: lights and buttons, not pricing pages. But the underlying mechanism—more discriminable alternatives require more processing before a response—generalizes cleanly to interfaces. A dropdown with 4 items resolves almost instantly. One with 40 forces scanning, comparing, and often abandoning.
Product teams tend to internalize a different, competing instinct: "give users control." Every stakeholder wants their edge case covered by a toggle. Every power user asks for a setting. Individually reasonable, collectively they build an interface that violates Hick's Law by accretion—nobody added the choice overload on purpose, but it arrived anyway.
Why This Differs From Simple Clutter
Hick's Law is not the same complaint as "the screen looks busy." A page can look sparse and still present a punishing decision—one CTA button with unclear consequences can stall a user longer than ten well-labeled ones. The variable that matters is discriminability under a decision, not raw element count. That distinction connects directly to broader cognitive load principles that govern why a simple-looking screen can still overwhelm.
Where Choice Overload Actually Shows Up in Products
Choice overload concentrates in three predictable places: settings panels, pricing pages, and navigation menus. Each has a distinct failure signature, and each responds to a different mitigation, so diagnosing which one you have matters before you prescribe a fix.
Settings panels are the most common offender because they grow by addition and never by subtraction. Every feature ships with a toggle "just in case," and nobody owns the job of removing stale ones. The result is a page where 80% of options are used by under 5% of the user base, but everyone pays the scanning cost.
Pricing pages trigger a related but distinct phenomenon: the paradox of choice, described by psychologist Barry Schwartz. More plans don't convert better past a threshold—they produce comparison paralysis, second-guessing, and in some cases outright abandonment because the "wrong choice" feels costly and irreversible.
Navigation menus fail when categories are flat instead of hierarchical. A 25-item top-level nav forces the Hick's Law penalty on every single visit, regardless of what the visitor actually needs that day.
| Surface | Common failure mode | Typical fix |
|---|---|---|
| Settings panel | Every feature gets a toggle; none get removed | Smart defaults + "Advanced" disclosure |
| Pricing page | Too many tiers create comparison paralysis | 3-tier structure with one recommended plan |
| Navigation menu | Flat list of 15-30 items | Categorized menu + search |
| Onboarding flow | All configuration surfaced up front | Defer non-essential choices to in-context moments |
Two sentences of takeaway: the fix is rarely "remove features." It's almost always sequencing—deciding what must be decided now versus what can wait until the user has context to decide well.
Why "Give Users Control" Is the Wrong Default Instinct
The instinct to maximize user control feels respectful of user autonomy, but it silently outsources design work to the user. Every unresolved decision you hand off is cognitive labor you didn't do—and most users will do it worse, more anxiously, and more slowly than a well-chosen default would have.
This isn't an argument against configurability. It's an argument against configurability as the default state of an interface. Progressive disclosure—a term formalized in usability literature by Jakob Nielsen and popularized through Apple's and Google's design guidelines—solves this by separating what's shown immediately from what's available on request.
- Start with a curated default that works for the majority use case without any input.
- Group remaining options by the job they serve, not by when the engineering team built them.
- Reveal advanced options behind a single, clearly labeled expansion—"Advanced settings," "More options," "Customize"—so the choice to go deeper is itself a deliberate, low-cost decision.
- Track which advanced options actually get touched, and periodically promote or retire them based on real usage, not stakeholder requests.
This shift matters most in settings and configuration surfaces, where the temptation to expose every internal flag is strongest. A PM auditing an existing settings screen should ask, section by section, "would 90% of users be fine never seeing this?" If yes, it belongs behind disclosure, not on the main pane. This kind of audit is also a natural moment to bring in a structured design critique rather than relitigating every toggle in isolation.
Smart Defaults, Categorization, and Progressive Disclosure as Mitigations
The three real mitigations for choice overload work together rather than as substitutes: smart defaults reduce the decisions a user has to make at all, categorization reduces the effort to scan the decisions that remain, and progressive disclosure controls when the remaining complexity becomes visible.
Smart Defaults
A smart default is a pre-selected value chosen from real usage data or a well-reasoned majority case, not an arbitrary first item in a list. The best defaults are reversible and clearly marked as changeable, so they read as a starting point rather than a trap.
- Default the pricing page's recommended plan based on actual conversion data, not the highest-margin tier.
- Default new users into the most common notification setting, not "all notifications on."
- Default a form to the last-used value when the same user returns, reducing repeat decisions to zero.
Categorization
Flat lists force linear scanning; categorized lists let users jump straight to the relevant cluster. Miller's classic "magical number seven" heuristic is often over-applied, but the underlying point holds directionally: once a single group of options exceeds roughly 7-9 items, splitting it into labeled subgroups measurably reduces scan time.
Progressive Disclosure
Progressive disclosure is the delivery mechanism for both of the above—it lets a product show a clean, decided-for-you default state while keeping every advanced option reachable, just not immediately visible. Done well, novice and expert users get genuinely different experiences of the same interface without a separate build for each.
Progressive disclosure isn't hiding features from users—it's sequencing when a decision is asked of them.
How to Prototype the Difference Before You Ship It
The fastest way to convince a skeptical team that "fewer options" beats "more control" is to let them feel both versions side by side, rather than argue about it in the abstract. A stripped-down option set often reads as obviously better the moment it's tangible, even when it was a hard sell on a slide.
This is exactly the kind of comparison Prodinja's Wireframing composer is built for: a PM can prototype a stripped-down option set—say, a 3-tier pricing page instead of a 7-tier one, or a settings pane with six visible controls instead of twenty—and put it next to the current version to feel the decision-time difference before committing engineering time to either. It's a lightweight way to test the Hick's Law hypothesis on your own product rather than importing it as an abstract rule from a psychology paper.
Once a reduced version proves out, the harder organizational work is prioritizing which existing options get demoted to "advanced" versus cut entirely—a sequencing problem more than a design one. That decision benefits from being run through a structured prioritization process rather than settled by whoever argues loudest in the review.
Key Takeaways
- Hick's Law predicts decision time grows with option count and complexity, not just visual clutter—a sparse screen can still overload a decision.
- Settings panels grow by accretion; without a periodic audit and removal process, they accumulate toggles nobody uses but everyone must scan.
- Pricing pages suffer from the paradox of choice—more tiers create comparison paralysis rather than better conversion past a certain point.
- "Give users control" should not be the default state of an interface; it silently transfers design labor onto the user.
- Smart defaults, categorization, and progressive disclosure work together: defaults cut decisions, categories cut scan time, disclosure controls when complexity appears.
- Prototyping a stripped-down option set is often more persuasive than arguing the principle in a meeting.
Frequently Asked Questions
What is Hick's Law in UX design?
Hick's Law in UX is the principle that the time it takes a user to make a decision increases with the number and complexity of choices presented, following a roughly logarithmic curve. It means adding options never scales for free—each new choice adds measurable decision latency.
How many options is too many for a menu or settings page?
There's no universal hard number, but usability heuristics built on Miller's classic "seven plus or minus two" research suggest that once a single flat list exceeds about 7-9 items, users benefit from categorization or disclosure rather than more scrolling. Treat that as a directional trigger, not a strict ceiling.
Does reducing pricing tiers actually improve conversion?
Directionally, yes for most products: research popularized by Barry Schwartz's paradox-of-choice work shows that excessive options increase comparison anxiety and can suppress decisions rather than aid them. The safest fix is a simplified 3-tier structure with one clearly recommended plan, validated against your own conversion data rather than assumed universally.
Is progressive disclosure the same as hiding features from users?
No—progressive disclosure means sequencing when a choice becomes visible, not removing it. Core, high-frequency options stay on the main screen; secondary options move behind a clearly labeled "Advanced" or "More options" control that any user can open at will.
How do I know if my product has a choice-overload problem?
Audit any screen with more than a handful of simultaneous decisions and ask whether 90% of users would be fine never seeing most of them. If usage data shows a small fraction of options driving nearly all engagement, the rest are candidates for defaults or disclosure rather than permanent visibility—an assessment that pairs well with a broader design literacy practice for PMs who don't come from a design background.
This kind of choice-architecture work sits inside the larger discipline covered in the complete guide to product design and UX, and it connects naturally to how a customer journey maps where decision points cluster, and to the underlying jobs users are hiring your product to do when they open a settings page in the first place.