--- title: 'Cognitive Load' source: 'https://academia.sh/en/courses/user-experience/cognitive-load' course: 'User Experience and Behavior Design' language: en updated: '2026-08-19T05:19:57+00:00' license: 'CC BY-SA 4.0' --- # Cognitive Load Computing the effect of the number of options on decision time with the Hick–Hyman relation, grouping's counterintuitive result, counting independent decision points on a screen, and the effect of decision fatigue on error rate. The previous lesson showed that switching to the deliberative system has a cost but assumed the cost was fixed: 1.4 seconds per record. That assumption holds only as long as the number of records in the list does not change. In the catalog interface, though, the number of options takes a different value on every screen: twenty-four criteria in the filter panel, five in the sort dropdown, six in the delivery branch list. This lesson establishes the relation between the number of options and decision time, counts the independent decision points in the borrowing flow, and computes how that load converts into an error rate. One of the results will show that a familiar piece of design advice does not hold up against measurement. ## Decision Time Is the Logarithm of the Number of Options The time it takes to choose among $n$ equiprobable options is proportional not to the number of options but to the **amount of information** the options carry. The **Hick–Hyman relation** writes this as: $$T = a + b \cdot \log_2(n + 1)$$ Here $a$ is the decision-independent fixed delay (perception and action), and $b$ is the decision time per bit. The $n + 1$ term accounts for the "choose none" option. The intuition the relation carries is this: choosing works like a binary search. The user does not review options one by one; they successively halve the set. Doubling the number of options adds a single bit to the time. **Cognitive load** is the sum of these bits: the amount of information the user must process to complete a task. Because load is a measurable quantity, the design decision becomes measurable as well. ## Counting the Borrowing Flow's Load The computation below does three things: it derives the options-versus-time curve, compares a flat list against a grouped list, and counts the independent decision points in the catalog interface's borrowing flow to give the total load. ```js // load.mjs — Hick-Hyman decision time, grouping, and on-screen decision points const A = 0.20; // s — decision-independent fixed delay (perception + action) const B = 0.15; // s/bit — decision time per bit const log2 = (x) => Math.log(x) / Math.LN2; const equalOddsTime = (n) => A + B * log2(n + 1); // Hick's law const entropy = (p) => -p.reduce((t, x) => t + (x > 0 ? x * log2(x) : 0), 0); const entropyTime = (p) => A + B * entropy(p); // Hyman generalization // 1) Effect of the number of options in the filter panel on decision time console.log("options info (bits) decision time"); for (const n of [2, 4, 8, 12, 16, 24, 32]) { console.log(`${String(n).padStart(7)} ${log2(n + 1).toFixed(3).padStart(12)} ${(equalOddsTime(n).toFixed(3) + " s").padStart(13)}`); } // 2) Comparing a flat list against two-stage grouping (24 filter options) console.log("\nlayout comparison for 24 filter options"); const flat = equalOddsTime(24); const grouped = equalOddsTime(4) + equalOddsTime(6); // first the group, then within the group const grouped3 = equalOddsTime(3) + equalOddsTime(8); const grouped2 = equalOddsTime(2) + equalOddsTime(12); console.log(`flat list (24) ${flat.toFixed(3)} s`); console.log(`4 groups x 6 options ${grouped.toFixed(3)} s (diff ${(grouped - flat).toFixed(3)} s)`); console.log(`3 groups x 8 options ${grouped3.toFixed(3)} s (diff ${(grouped3 - flat).toFixed(3)} s)`); console.log(`2 groups x 12 options ${grouped2.toFixed(3)} s (diff ${(grouped2 - flat).toFixed(3)} s)`); // 3) When usage distribution is not equiprobable: Hyman entropy console.log("\nwhen usage distribution is not equiprobable (24 options)"); const equalProb = Array(24).fill(1 / 24); // Observed usage: three filters heavily weighted, the remaining 21 rare const observed = []; const heavy = [0.34, 0.26, 0.17]; for (const p of heavy) observed.push(p); for (let i = 0; i < 21; i++) observed.push((1 - 0.77) / 21); console.log(`equiprobable distribution entropy ${entropy(equalProb).toFixed(3)} bits time ${entropyTime(equalProb).toFixed(3)} s`); console.log(`observed distribution entropy ${entropy(observed).toFixed(3)} bits time ${entropyTime(observed).toFixed(3)} s`); console.log(`gain from ordering by frequency: ${(entropyTime(equalProb) - entropyTime(observed)).toFixed(3)} s`); console.log(`gain from grouping (under the equiprobable assumption): ${(flat - grouped).toFixed(3)} s`); // 4) Counting independent decision points in the borrowing flow // Each decision point: an area where the user must make a choice, independent of the others. const FLOW = [ { screen: "search", points: [["search field", 1], ["scope selection", 3], ["sorting", 5]] }, { screen: "result list", points: [["filter panel", 24], ["sorting", 5], ["page size", 4], ["record selection", 20]] }, { screen: "record detail", points: [["copy selection", 3], ["borrow / reserve / add to list", 3]] }, { screen: "borrow confirmation", points: [["delivery branch", 6], ["duration selection", 3], ["reminder preference", 4], ["confirmation", 2]] }, ]; console.log("\nscreen decision points total bits decision time"); let totalBits = 0, totalTime = 0, totalPoints = 0; for (const { screen, points } of FLOW) { const bits = points.reduce((t, [, n]) => t + log2(n + 1), 0); const time = points.reduce((t, [, n]) => t + equalOddsTime(n), 0); totalBits += bits; totalTime += time; totalPoints += points.length; console.log(`${screen.padEnd(22)} ${String(points.length).padStart(15)} ${bits.toFixed(2).padStart(11)} ${(time.toFixed(2) + " s").padStart(13)}`); } console.log(`${"TOTAL".padEnd(22)} ${String(totalPoints).padStart(15)} ${totalBits.toFixed(2).padStart(11)} ${(totalTime.toFixed(2) + " s").padStart(13)}`); // 5) Decision fatigue: error probability rises as bits spent accumulate // p_error(x) = p0 + k * (x / budget)^2 ; x = bits spent so far const P0 = 0.02, K = 0.16, BUDGET = 32; function flowError(flow) { let spent = 0, expectedError = 0; for (const { points } of flow) { for (const [, n] of points) { const bits = log2(n + 1); const p = Math.min(1, P0 + K * Math.pow(spent / BUDGET, 2)); expectedError += p; spent += bits; } } return { spent, expectedError }; } const before = flowError(FLOW); console.log(`\nbits spent ${before.spent.toFixed(2)}, expected number of wrong choices ${before.expectedError.toFixed(3)}`); // 6) Reduced flow: fields with defaults stop being decision points const REDUCED = [ { screen: "search", points: [["search field", 1]] }, { screen: "result list", points: [["filter panel (4 groups)", 4], ["in-group selection", 6], ["record selection", 20]] }, { screen: "record detail", points: [["borrow / reserve / add to list", 3]] }, { screen: "borrow confirmation", points: [["confirmation", 2]] }, ]; const after = flowError(REDUCED); const reducedTime = REDUCED.reduce((t, e) => t + e.points.reduce((s, [, n]) => s + equalOddsTime(n), 0), 0); const reducedPoints = REDUCED.reduce((t, e) => t + e.points.length, 0); console.log(`reduced flow: ${reducedPoints} decision points, ${after.spent.toFixed(2)} bits, ${reducedTime.toFixed(2)} s, expected wrong choices ${after.expectedError.toFixed(3)}`); console.log(`gain: ${(totalPoints - reducedPoints)} decision points, ${(totalTime - reducedTime).toFixed(2)} s, ${((1 - after.expectedError / before.expectedError) * 100).toFixed(1)} % fewer expected errors`); ``` ``` options info (bits) decision time 2 1.585 0.438 s 4 2.322 0.548 s 8 3.170 0.675 s 12 3.700 0.755 s 16 4.087 0.813 s 24 4.644 0.897 s 32 5.044 0.957 s layout comparison for 24 filter options flat list (24) 0.897 s 4 groups x 6 options 1.169 s (diff 0.273 s) 3 groups x 8 options 1.175 s (diff 0.279 s) 2 groups x 12 options 1.193 s (diff 0.296 s) when usage distribution is not equiprobable (24 options) equiprobable distribution entropy 4.585 bits time 0.888 s observed distribution entropy 2.967 bits time 0.645 s gain from ordering by frequency: 0.243 s gain from grouping (under the equiprobable assumption): -0.273 s screen decision points total bits decision time search 3 5.58 1.44 s result list 4 13.94 2.89 s record detail 2 4.00 1.00 s borrow confirmation 4 8.71 2.11 s TOTAL 13 32.24 7.44 s bits spent 32.24, expected number of wrong choices 0.943 reduced flow: 6 decision points, 14.11 bits, 3.32 s, expected wrong choices 0.170 gain: 7 decision points, 4.12 s, 82.0 % fewer expected errors ``` ## Adding an Option Is Cheap, Adding a Decision Point Is Expensive The first table shows what logarithmic growth means in practice. As the number of options rises from two to thirty-two — a sixteenfold increase — decision time rises from 0.438 seconds to 0.957 seconds, only a 2.2-fold increase. The cost of going from eight options to sixteen is 0.138 seconds. This means adding an option to a single dropdown is cheap. What is expensive is something else, and it shows up in the fourth table: **adding a separate decision point.** Every decision point charges the $a$ constant again. The two decision points on the third screen cost 1.00 second total; 0.40 seconds of that, 40 percent, comes not from the number of options but from the number of decision points. The rule is this: **a single field with twelve options is cheaper than four fields with three options each.** The computation confirms it — a single field with twelve options costs 0.755 seconds; four fields with three options each cost $4 \times 0.500 = 2.000$ seconds. ## Grouping's Effect Is the Opposite of Expected The second table contradicts a piece of design advice given often. A flat list of twenty-four options costs 0.897 seconds; the same twenty-four options split into four groups cost 1.169 seconds. Grouping **increases** decision time **by 0.273 seconds**, it does not reduce it. The reason is the rule from the previous paragraph: grouping turns a single decision point into two, and the $a$ constant is paid twice. This result does not mean grouping is wrong; it means grouping **is not done for decision time.** Grouping reduces a different cost: the cost of **finding** the option the user is looking for in the list. In an unlabeled list of twenty-four items, the user has to read the items; in a list with four headings, they read under only one heading. The Hick–Hyman relation assumes the option is already known — it does not account for the search cost. The two costs are measured separately and justified separately. The third table shows a bigger gain. When filter usage is not equiprobable — when 77 percent of users use only three criteria — entropy drops from 4.585 bits to 2.967 bits, and time drops from 0.888 seconds to 0.645 seconds. The gain from putting frequently used filters first is 0.243 seconds; grouping's "gain" is minus 0.273 seconds. The most efficient way to reduce load is not rearranging the options but **reflecting the usage distribution in the interface.** This has one precondition: knowing the usage distribution. That distribution is obtained by measurement, not by guessing; it is the subject of the measurement topic. ## Fatigue Is the Load's Second Bill The fifth computation models a second cost of load beyond time. The user's attention is limited, and error probability rises as it is spent. In the model, error probability grows with the square of the number of bits spent so far. The entire borrowing flow costs thirteen decision points and 32.24 bits. At this load, the expected number of wrong choices is 0.943 — every user who completes the flow gets, on average, one decision wrong. A wrong decision tends to be a decision near the end of the flow; the most tired moments come on the last screen. In the catalog interface, that screen is the borrow confirmation: the delivery branch, the duration, and the reminder preference are chosen there. A book ordered to the wrong branch is the user's most expensive mistake. The sixth computation removes seven decision points. The removed fields do not disappear; they take on a **default** value. The delivery branch defaults to the branch the user belongs to, the duration to the longest duration, the reminder preference to on. The user can change them if they want, but as long as they do not, they are not forced to decide. The result: 3.32 seconds instead of 7.44, and 82 percent fewer expected errors. Two separate conclusions follow from this, and they must not be conflated. The first is a design gain: a decision not asked of the user is better than a decision left unmade. The second is a warning: setting a default takes the decision away from the user and gives it to the designer. The three defaults above serve the user's interest — the user would have chosen the same thing had they known. The same mechanism can be built against the user's interest. The power of defaults, and the limit of that power, is the subject of a separate lesson. ## The Practical Way to Measure Load Measuring a screen's load does not require a design tool; counting is enough. **Count the independent decision points.** Every field where the user must assign a value is a point. If the value is pre-filled and the user can move on without touching it, the point does not count. **Write down each point's number of options and sum $\log_2(n+1)$.** The total is the screen's load in bits. Comparisons between screens are made with this number. **Track the total bits across the same flow.** Fatigue accumulates over the flow; screens that look reasonable one at a time may not be reasonable once summed. **Order options by the usage distribution.** Frequency ordering yields a bigger gain than grouping and adds no decision point. ## Summary - The Hick–Hyman relation ties decision time to the logarithm of the number of options: $T = a + b \log_2(n+1)$; doubling the number of options adds one bit to the time. - Adding an option is cheap, adding a decision point is expensive; a single field with twelve options is chosen roughly 2.6 times faster than four fields with three options each. - Grouping does not reduce decision time — in the computation it adds 0.273 seconds; grouping is justified not by decision time but by the cost of finding an option in the list. - When the usage distribution is not equiprobable, entropy drops; ordering filters by frequency gains 0.243 seconds and adds no decision point. - Load accumulates over a flow and raises error probability; when a thirteen-point borrowing flow is reduced to six points, expected wrong choices drop by 82 percent. - Setting a default takes the decision away from the user and gives it to the designer; both the gain and the risk come from that. ## Next Step This lesson measured **how hard** the user finds a decision. What it did not measure is not making the decision at all. The catalog user may never complete the borrowing flow; they may not even start it, even when the load is low. The next lesson establishes which three conditions must hold at the same time for a behavior to occur, and computes which of those conditions is worth intervening on to bring more users into the flow.