Even successfully maintaining a flow state doesn't seem to do much about the limitations of human memory. As we noted under the Rule of Seven in the Premises chapter, these limitations have implications that echo all through UI design.

Human memory works much like a virtual-memory system, in that it is divided into short-term and long-term storage with a relatively high cost for pushing data from the short-term working set out to long-term memory.

The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information [Miller] is one of the foundation papers in cognitive psychology (and, incidentally, the specific reason that U.S. local telephone numbers have seven digits). Miller showed that the number of discrete items of information human beings can hold in short-term memory is seven, plus or minus two.

We've already observed than any hidden state in a program is likely to take up at least one of these scarce slots. We have further observed that having more than seven visible controls on a program's interface is likely to collide with this limit as well; using the controls involves refreshing short-term memory with retrieved knowledge about them, and if that retrieved knowledge doesn't fit easily in the working store, the cognitive cost of using the interface increases. We can use the timings reported earlier in this chapter to be more specific; the penalty for going over our 7±2 working store sizes implies a long-term memory retrieval for every extra slot, with an expected time penalty of about 1.2 seconds each.

Humans compensate for the limited size of their working set in two main ways: selective ignorance and chunking strategies. If the main panel of a GUI has thirteen buttons, users will often quickly figure out that they can ignore five of them for normal use and group some others into chunks that can be remembered as groups rather than individually, with the meaning of the individual group members being swapped in whenever the user determines that the next operation needed is probably in that group.

In fact, developing this kind of implicit knowledge is a large part of what we mean by “learning” an interface, another kind of habit formation that builds expertise. Therefore, good interface designs allow selective ignorance and encourage chunking. Well-designed UIs often include visual aids to chunking, such as box rules around groups of related controls. More fundamentally, strong functional metaphors in programs are aids to chunking. Orthogonality of features helps make features ignorable.

It is wise not to lean on the user's chunking capacity and ability to selectively ignore features too hard, because those capabilities have costs and require effort. The more you can hold the number of items a user must grasp at any one time below seven, the happier and more comfortable they will be.

It is especially important for expert programmers to internalize this habit, for two reasons. One is that expert programmers are disproportionately drawn from the high end of the bell curve in their working-set size; therefore they tend to systematically overestimate the amount of complexity other people can handle easily.

The other is that, for a particular well-known task, apparent working-set size can increase because some knowledge about the interface has been committed to long-term memory. Expert programmers tend to evaluate interfaces by what they are like when they are familiar (e.g. a lot about them has gone into long-term storage); thus they systematically underestimate the degree to which complex interfaces strain the novice user and present barriers to learning.

Thus, for an audience of programmers, we emphasize the number seven. It may not be right in all circumstances, but using it as a hard threshold will bias programmers in a good direction, which is simpler than their own reflexes and working-set size would usually take them.