UX Calculation for non equally probable choices?

Question

We are redesigning an HR portal, and we are flowing options differently than before, by bundling logical groups in "areas", rather than having a large page with 30+ links. So rather than scanning an entire page looking for something like a tax form, they would first click on a pay and taxes area, which would have a few options related only to pay and taxes.

I would like to quantify the time using something like Hick's law, but Hick's law seems to apply to equally probable choices in a situation, rather than scanning and finding on a single page, rather than being "funneled" along.

Does a calculation like this exist, where the number of possible options to scan can quantitatively impact the time it takes to find?

Answer 1

On breadth versus depth...

Yes, this topic has been studied with some rigor by the academic and professional community. You can do a search for "menu breadth versus depth" to get a good sampling of papers and articles out there, but the quick summary is:

• Generally, breadth has been proven to be more effective than depth across many different dimensions of speed, user experience, productivity, etc.

• There is a limit to breadth. Some studies have found that beyond 8 or 16 choices, it's better to nest options.

• There is also a limit to depth. Multiple studies suggest that there is a significant difference in performance between 2 (better) and 3+ (worse) levels of nested navigation.

• Since you asked about calculation, some academics have attempted top-down calculations of the ideal breadth cutoff, but I wouldn't recommend relying on these heuristics. For example, this textbook outlines one approach. Another approach documented here yields the following curve, which I also would not rely on:

The papers by Larson and Czerwinski (1998) and Miller (1981) are good references and you can follow the citations for more links. This book excerpt provides some overview too.

On frequency distribution of buttons

• This is a bit more complicated, because it involves multiple tradeoffs. Generally, a flat, organized view of links/buttons is a good way to present a broad set of links on a page. You can do this using islands, or using a indented hierarchy.

• Frequency is sometimes orthogonal to category (e.g. the most common tasks for a city website may be pay taxes, or pay traffic tickets, but taxes and parking are in two different categories so there is a tradeoff involved). So designing the right layout to incorporate frequency will usually involve a reasoned decision that balances out the need to organize the broad information base with the need to show frequent options prominently.

  • This decision plays out very differently in different contexts, so it's hard to make a recommendation here (i.e. it's beyond the scope of the question, probably).

Answer 2

Hick’s Law does not necessarily require equally probable choices. Only the simplified version T = b Log2 (n + 1) does. It is algebraically derived from the “full” theory, which is T = b Sum( p(i) Log2(1/p(i) + 1) ), where p(i) is the probability of a choice i.

Hick’s Law can be combined with other calculations to predict average menu item selection time, as described in the cites tohster provided. An algorithm for determining the "optimal" hierarchy can be found in:

Fisher DL, Yungkurth EJ, Moss SM, 1990. Optimal menu hierarchy design: Syntax and semantics. Human Factors, 32(6) 665-683.

Such approaches can be quite accurate for comparing alternatives if you use quantitative observations of your own users and system for input parameters (e.g., reading time of your users reading your menu items, selection time by your users of your menu implementation). Even still, the results are only approximations –good for making a reasonable stab at the problem, but not necessarily the true optimal. These approaches don’t take into account things like how well semantically organized a given menu is, or the fact the higher level menu items tend to have more abstract labels which are harder to interpret.

If you really need the super-most-optimal design, use the approaches to narrow the possibilities down, and then race them against each other in a quantitative usability test. Be prepared to run many trials –the average differences will be small and hard to detect. Whether super-optimizing is economically justifiable depends on how many uses of the menu you'll have over the lifetime of the product -will shaving a second pay for the effort to do the test?