Neuroeconomics and user interactions

January 4, 2017

In 1999, an experiment was conducted at the University of Iowa in which 82 undergraduate students were subjects of some remarkable findings. Half of the students were randomly assigned to memorize a two-digit number and the other half a seven-digit number. After completing this task, the students were told that the experiment was over and given a snack. They could choose either fruit salad or chocolate cake.

Students who memorized seven-digit numbers were 50 percent more likely to pick chocolate cake as their snack.

What does this mean?

The researchers, Dr. Baba Shiv and Alex Fedorikhin, concluded that willpower and mental capacity come from the same cognitive reserves. In other words, we each have a finite reserve of mental power. If you deplete your mental reserves, subsequent decisions will be driven by impulse and/or emotion rather than deliberate forethought.

Why is this?

To answer why, we have to look at what makes chocolate cake more appealing than fruit salad.

According to Shiv and Fedorikhin, chocolate cake is associated with more intense positive effect but less favorable cognitions. Fruit is associated with less favorable effect but more favorable cognitions.

One way to explain this difference is to consider that eating chocolate cake tends to provide immediate and intense positive feelings that dissipate quickly, whereas eating fruit salad tends to provide a longer-lasting satisfaction knowing one made the healthier choice.

Additional laboratory studies have found that decisions draw from our mental reserves, and decisions that override our impulse for instant gratification deplete it even quicker. The important takeaway here is that we each have a finite mental capacity, and every decision we make reduces it.

This may explain why some highly successful people tend to wear the same clothing every day.

“I really want to clear my life to make it so that I have to make as few decisions as possible about anything except how to best serve this community." — Mark Zuckerberg

How does this relate to user interfaces or interactions?

This has ramifications for how users interact with an application. Every time Wdesk users have to evaluate the user interface and choose how best to accomplish a task, they’re making choices and burning through those cognitive reserves. Another helpful tool in looking at this is to consider Hick’s Law.

Hick’s Law describes the time it takes for a person to make a decision as a result of the possible choices he or she has. Increasing the number of choices will increase the decision time logarithmically.

For example, when a user wants to press a specific button, Hick’s Law predicts that the greater the number of alternative buttons, the longer it will take to make the decision and select the correct button.

The formula that governs Hicks law is:

Reaction Time = Movement Time + Processing Speed * log2 (n)

Processing Speed * log2 is the time taken to come to a decision, n is the number of choices and Movement Time is the total time that is not involved with decision-making.

Hick’s law in action

Let’s take this one step further and apply Hick’s law to a menu in which we modify text:

Case 1: Two menu buttons

For demonstration purposes, let’s consider that a user would like to apply one of these two options to some text. For the sake of brevity, let’s set our movement time to an arbitrary constant value of 55 ms and the processing speed to 300 ms.

If we apply this formula to our use case, we see that our equation becomes:

Reaction Time = 55 + 300 * log2 (2)
Reaction Time = 355 ms

Based on this formula, we predict that it will take a user 355 ms to select one of these options.

Case 2: Four menu buttons

What would happen if we added two more options? How will that impact the length of time a user takes to make a decision?

If we apply this formula to our updated use case, we see that our equation becomes:

Reaction Time = 55 + 300 * log2 (4)
Reaction Time = 655 ms

Based on this formula, we predict that it will take a user 655 milliseconds to select one of these four options. That’s an increase of 84.5 percent.

I’m not suggesting we reduce our user interfaces with fewer buttons. Hick’s law becomes less relevant the more options that are available. For example, a menu with 21 items yields a decision duration increase of only around two percent over a menu with 20 items.

This is a tool for understanding how choices become harder to make the more options we have to evaluate.

When considering this trend, several other questions arise:

  • Do users prefer more complicated user interfaces as these findings suggests?
  • Does user-interface complexity need to increase as an application itself increases in complexity?
  • ​​​Since user-interface complexity can negatively impact a user’s efficiency, how do we ensure our user interfaces are simple to use yet complex enough to be useful?

Maybe Einstein can lend his insight:

How do we measure user interface simplicity?

I propose that if we want to measure how simple a user interface is, we have to guide that measurement by what the user is attempting to accomplish. In other words, we typically design user interfaces for the purposes of a specific task, so it makes sense to measure simplicity within the context of a task.

As early as 1979, when Visicalc gave us our first spreadsheet software, we’ve been searching for ways to measure our interactions with computers.

That same year, in a study from the U.S. Department of Commerce on the literature surrounding human computer interactions, researchers concluded: “While there exists enough material to develop a qualitative 'human factors design guide,’ there is insufficient material for a ‘quantitative reference handbook.'”

This realization prompted the creation of several new techniques for measuring a user's ability to effectively interact with a computer, including first-click testing, completion rates, and keystroke-level modeling.

Keystroke-level modeling (KLM) was proposed in 1983 as a means of predicting the minimum time that a user needs to accomplish a task on a specific design. It is of particular relevance to our products because it accurately predicts how efficient a given user interface is in allowing a user to accomplish a specific task.

This also means that the technique is specifically suited toward competent users rather than more casual ones. Given that the Workiva user base is generally well-versed in accounting software, we theorize that this is a good match for testing our own relative simplicity.

To test out this theory, we set out to apply KLM to probably our most important user activity: creating links by copying and pasting data.


Use Case: How to copy and paste data

There are typically two ways a Wdesk user can create a link.

Method 1: Keyboard shortcut

  1. Select a piece of data by pointing to it, and then clicking on it

  2. Press ctrl+c to copy

  3. Select where you would like to paste your link by pointing to it, then clicking on that spot

  4. Press ctrl+v to paste

Method 2: Right-click context menu

  1. Select a piece of data by pointing to it, and then click on it

  2. Right click, and then select copy from context menu

  3. Select where you would like to paste your link by pointing to it, and then click on that spot

  4. Right click, and then select paste from context menu

Applying keystroke-level modeling

At its core, KLM is a set of operators that describe the mental and physical actions a user will take to accomplish a specific task with a given user interface.

Operators and times

The following are the standard operators and estimated times for each operator.

K — Keystroke (.12 – 1.2 sec; .28 recommended for most users). This operator is pressing a key or button on the keyboard. Pressing the SHIFT or CONTROL key counts as a separate keystroke. Different experience levels have different times for the K operator:

Expert typist (90 wpm): .12 sec
Average skilled typist (55 wpm): .20 sec
Average nonsecretarial typist (40 wpm): .28 sec
Worst typist (unfamiliar with keyboard): 1.2 sec

The average nonsecretarial typist (.28 sec) is a good design point for characterizing the typical computer user. These are people familiar enough with the keyboard to use it fluently, but they are not professional-grade typists.

T(n)Type a sequence of n characters on a keyboard (n * K sec). This operator is simply a shorthand for a series of K operators and would normally be used only when the user is typing a string of characters that is a single chunk, such as a filename.

P — Point with mouse to a target on the display (1.1 sec). This operator represents the action of moving the mouse to point the cursor to a desired place on the screen. The actual time required can be determined from Fitts' law. For typical situations, it ranges from .8 to 1.5 sec, with an average of 1.1 sec. If great accuracy is not required or the movement distances or target sizes are not unusual, this average can be used instead of more precise times.

B — Press or release mouse button (.1 sec). This is a highly practiced, very rapid movement. Figure .1 sec for pushing the button down or letting it up.

BB — Click mouse button (.2 sec). Pushing and releasing the mouse button rapidly, as in a selection click, counts as two B operators, for a total of .2 sec.

H — Home hands to keyboard or mouse (.4 sec). Since the targets are large and the movement is well-practiced, moving the hand between keyboard and mouse and vice-versa is relatively fast.

M — Mental act of routine thinking or perception (.6 - 1.35 sec; use 1.2 sec). This operator is based on the fact that when reasonably experienced users are engaged in routine operation of a computer, there are pauses in the stream of actions that are about a second long and that are associated with routine acts such as remembering a filename or finding something on the screen. The M operator is intended to represent this—routine thinking; noncomplex, lengthy, problem-solving; racking the brain; or creative meditations. In a variety of routine computer usage tasks such as word processing and spreadsheet usage, these routine pauses are fairly uniform in length, justifying the assumption that all Ms take the same amount of time, around one sec. Based on the available results, a good overall estimate for the duration of an M is 1.2 sec.

W(t) — Waiting for the system to respond (time t must be determined). This is the time that the user must wait on the system before he or she can proceed. Notice that it is not necessarily the same as the time required by the system because the user may be able to overlap other activities while the system is working.

Operator sequence

Now lets apply these operators to the process of copying and pasting data in Wdesk.

Method 1: Keyboard shortcut

  1. Select a piece of data by pointing to (P), and then click on it (B+B)

  2. Press ctrl+c (H+K+K)

  3. Select where you would like to paste your link (M) by pointing to (P), and then click on that spot (B+B)

  4. Press ctrl+v (H+K+K)

Total time = P+B+B+H+K+K+M+P+B+B+H+K+K

                 = 1.1+0.1+0.1+0.4+0.28+0.28+1.2+1.1+0.1+0.1+0.4+0.28+0.28

                 = 5.72 seconds

Method 2: Right-click context menu

  1. Select a piece of data by pointing to (P), and then click on it (B+B)

  2. Right click (B+B), then find (M), and select (P+B+B) copy from context menu

  3. Select where you would like to paste your link (M) by pointing to (P), and then click on that spot (B+B)

  4. Right click (B+B), then find (M), and select (P+B+B) paste from context menu

Total time = P+B+B+B+B+M+P+B+B+M+P+B+B+M+P+B+B+B+B+M+P+B+B

                 = 1.1+0.1+0.1+0.1+0.1+1.2+1.1+0.1+0.1+1.2+1.1+0.1+0.1+1.2+1.1+0.1+0.1+0.1+0.1+1.2+1.1+0.1+0.1

                 = 11.7 seconds


This chart summarizes the operators required by each method.




Point mouse (P)



Press/release mouse button (B)



Hand to keyboard or vice versa (H)



Mental activities (M)



Keystroke (K)



Total time (seconds)



With the copy and paste task, the right-click method is more than twice as slow as the keyboard shortcut. From the summary, It is easy to see that the problem with method 2 involves much higher fine motor demands, as well as quadruple the number of mental activities.

Not only are users performing far more physical work with method 2, they’re also making many more decisions, which we understand will deplete a user’s mental reserves quicker.


To quote researchers at Oracle:

KLM analysis of a user interface predicts the actual time of experienced users to within a manageable margin-of-error. We believe that we can now apply KLM analysis to new products to see if they are likely to enable users to be more productive than with a previous product. We can build these productivity estimates well before any code has been generated, which allows us to test and retest designs in moving towards the most productive interface.

The aim of any user interface is to facilitate the effortless execution of a task with as little neuro and motor effort as possible. By applying KLM to the goal of finding the right balance between complexity and usability, we assure ourselves of capable user interfaces that respect the demands we place on our users. These are vital aspects in our quest to help our users to work smart with Wdesk.