Reduce the number of choices shown at once

What it is

Twenty plans, twelve entries, and six buttons that all look like “continue” on one screen are not freedom of choice for someone with impaired executive function. They are a comparison task that already overflowed. Reduced simultaneous choices means: at a given decision point, the set the user must compare and pick from has to be small enough to finish, not a dump of every capability the product has.

The object of control is how many paths compete for the decision now. It is not how many features exist in the product, and it is not how many digits working memory can hold. Parking infrequent actions one step later, or offering a recommended path, counts. Drawing twenty buttons smaller so they still fit does not.

Why it happens

Every extra option has to be checked against the current goal. That goal itself is often held in working memory—and intellectual disability, TBI sequelae, early dementia, and ADHD-related executive impairment make that chain easy to drop. People do not “choose more slowly”; they abandon, tap at random, or bounce in and out.

Rising reaction time with the number of equally likely alternatives only explains that finding takes longer. The sharper cost is evaluation load: options are not identical keys, they have to be understood and the irrelevant ones inhibited. Inhibition is among the first capacities to go. So the adaptation is shrinking the set that must be evaluated together, pushing the next layer behind progressive disclosure, grouping, and a default—not treating a memory-span number as a cap on buttons per screen.

Studying it

Run a cognitive-accessibility walkthrough that counts, on each decision screen, the parallel controls that would take the task to different outcomes—not the raw DOM node count. Choice-overload studies (assortment size versus completion or abandonment) supply the shape of the effect, not an effect size to copy from a supermarket shelf: interface options carry unequal semantic weight and often include a default.

Independent variables: number of parallel primary paths, presence of a recommended item, whether groups are actually mutually exclusive. Dependent variables: first-hit rate on the intended path, abandonment, oscillations among options.

For switch-scanning users, option count also becomes scan steps, but that is an operability cost, not the main evidence here; the main evidence is whether comparison and inhibition overflow.

Where it stops holding

Experts recognising known tools in their own domain are not evaluating novel options; a dense palette can hold. Filters that narrow a set are not the same failure as spreading every option at once. Emergencies need one primary path, not every secondary action laid out beside it. Hiding options so they can never be found turns “fewer simultaneous choices” into feature deprivation—deferred options must actually appear after the current decision is made.

Applying it

• Keep one primary continue action per high-stakes view; demote rivals to text links or “other ways,” not equal-weight buttons.
• Disclose in stages: pick a class, then the items in that class. Do not spread every plan parameter on screen one.
• When a sensible default exists, present it with a reason so “do nothing extra” is still a completable path.
• Verify: screenshot each decision view, paint out decoration, and count every independent action that claims to continue the task. Fail if that set is larger than a small handful with no default. Then have someone who does not know the product (or a COGA-style heuristic pass) complete the main path without being told which control is “the” one. If they need a pointer to the primary button, simultaneous choice was not reduced.

Related

• Same group: J4.07.2 Give the interface a consistent, predictable structure · J4.07.3 Restate and confirm before critical actions
• Nearby: A6.10 Misuse of memory-span numbers · A6.02 Working memory capacity · J4.05 Plain language
• Search terms: reduced simultaneous choices · choice overload · cognitive accessibility