More options bring choice difficulty and decision regret

What it is

Seven usable subject lines, side by side. People have seen them — not failed to look — and every one could work. After picking, they start to wonder whether the fifth was better, and open the unchosen again. Choice overload and regret means that when count is high enough that comparison has happened and still cannot close, what is added is not information but difficulty ending the choice, and rumination on the unchosen after the pick.

Options that were never even looked at are a capacity problem. Here they were looked at; the pain is not being able to stop.

Why it happens

As options increase, imagined opportunity cost increases: each unchosen might have been better. Anticipated regret lengthens comparison; actual regret pins attention on the unchosen after the pick. If evaluation has more than one dimension (short, polite, specific), count makes incompatibility more visible, and the trade-off itself becomes the load.

Overload is not “cannot see them all.” When people cannot see them all they satisfice, and regret is often lower. Overload happens when every item in the window was processed and none wins on all dimensions. Generators are good at making sets that are all usable, each a little better at something.

Studying it

Set count to 2, 3, 5, 7, guaranteeing each was seen (fixation or forced expand). Dependent variables: time to decide, abandonment, looks back at the unchosen after the pick, a regret scale, whether the next request is “a few more.” Independent variables: count, dimensional conflict (one dimension vs. multi-dimension incompatibility).

Confirm every item was processed. Otherwise overload will be written up as a capacity failure. Looking back at the unchosen is a behavioural index of regret, harder than “do you regret it.”

Where it stops holding

Retrieval tasks (find the one that meets a hard constraint among many) benefit from count; overload is weak. When the user is exploring with no delivery moment, regret has no object. Experts with a stable lexical standard turn count into filtering and rarely regret. A set with huge one-dimensional gaps (one usable, six obviously not) will not overload. This entry does not treat unread excess, nor position sucking the choice.

Applying it

• Deliver side-by-side at a count that can be seen through and closed, usually two to four. Want more: “another batch,” not seven usables in one dump.
• After a pick, do not keep the unchosen in the primary view. Unchosen in sight is fuel for regret.
• On multi-dimension conflict, let people pick a dimension first (“short” or “specific”) rather than letting seven lines fight on every dimension at once.
• Check: seven usables side by side; record decision time and post-pick look-backs. Long time, many look-backs, plus “give me a few more,” is overload from count. Drop to three and both should fall.

Related

• Same group: L3.07.1 Juxtaposition drops the evaluation load from good-or-bad to which-is-better · L3.07.2 When options differ too little, comparison collapses into picking noise · L3.07.4 People favour the first and left positions; order must be controlled or randomised · L3.07.5 Multiple options expose the system’s instability — a cost and a form of honesty
• Nearby: L3.01 Generating Multiple Options · L1.01 Mismatch Between Stochastic Output and Deterministic UI
• Search terms: choice overload · decision regret · opportunity cost of unchosen