The project: We're designing software that users will use all day long to perform 12 repetitive tasks. Each task has many steps and takes place in a different pane in the GUI. Some of the GUI is tabbed. There may also be commands on ribbon-like galleys, similar to the large drop-down menus in newer versions of Microsoft Office.]

My question: what research is there that shows the performance benefit of keyboard navigation in groups of users who become expert users in a narrow but deep set of functions by necessity of their job?

Why I'm asking: I want to get my ducks in a row to be able to argue that we must not cut the keyboard navigation component of the project in order to meet our first release date. I don't expect to have it cut, but I do expect it to be raised as a possibility and I want to be ready. :)

[As a friend once told me, "Don't tell me worrying doesn't help. The things I worry about don't happen!"]

  • I'm looking for numbers—even if they are generalisations. For example, "A keyboard shortcut typically shaves 3% off task time." Actually, come to think of it, somewhere I have a textbook that gives these values. The assignments forced me to do calculations to predict time-on-task values of certain GUI designs. I may have the very answer I'm seeking. (What was the title of that pale-yellow textbook?)
    – JeromeR
    May 26, 2010 at 15:40

4 Answers 4


Nice question.

A concept to base some research on for this issue is "kinesthetic memory". Basically, the memory that your body has to complete tasks (such as playing the guitar without looking at the strings, touch-typing etc).

I've had a quick look around the web for useful articles, and here's an example. http://www.fast-consulting.com/gdhb/gdhb_keyboard.htm

Keyboard shortcuts take advantage of "body" or kinesthetic memory, which comes into play when you learn to type, ride a bicycle, or drive a car. This kinesthetic memory is the reason that touch-typists dislike interfaces in which too much functionality is tied to the mouse¾you can't memorize the mouse's location the way you can memorize keyboard positions. Keys are always in the same place. The mouse pointer rarely is.

I agree that removing the keyboard would be a big annoyance for constant users. I hope this article, and the topic of Kinesthetic Memory gives you some good 'ammunition' if you are asked to remove keyboard functionality!

/Edit - here's another article using the terminology 'Muscle Memory' http://www.simlog.com/muscle-memory.html

  • This is what I love about posing a question to a community. You get exposed to ideas that you never would have thought of on your own. ☺
    – JeromeR
    May 26, 2010 at 15:34

Looks into GOMS analysis. It can give you explicit timing for tasks using mouse vs. using keyboard. You will definitely be able to prove the difference this way.

  • One of the links off the page, above, gave me the following numbers: Keystroke: 280 ms/character. Complete mouse click: 200 ms. Double-click: 400 ms. Mouse down to start a drag: 100 ms. Mouse up to end a drag: 100 ms. Point mouse to target object: 1100 ms or consult Fitts' law. Move the hand between mouse and keyboard: 400 ms. This is exactly the kind of thing I was thinking of in the comment that I added to my own question, above.
    – JeromeR
    Jun 4, 2010 at 4:31
  • The researchers will be happy to know someone is actually using it...drop him a line if you end up with a success story! Jun 4, 2010 at 12:58

Another aspect to consider separate to productivity

Is there a legal requirement for you to ensure your software can work without a mouse? The answer to this will depend on where you are in the world, and what legal jurisdiction the business running the software is under.

For example, Im in New Zealand.

  • If this software was for members of the public to use over the internet, and the organisation was a government department, then we would be required to comply with WCAG 2.0 level AA -- which includes device independence.
  • If the software was for internal staff to use, regardless of how the interface was accessed (browser, stand-alone app) then the specific standards aren't directly named, but the organisation must comply with equal employment opportunity, health and safety, and human rights legislation. One of the best ways to comply with this legislation is to follow WCAG 2.0 AA.

Unless you can personally identify every single user of your software and identify any specific needs they have, including the use of assistive technologies, in order for them to do their day-to-day job, then there is a risk that some users will be unable to use the software.

On a personal note, if I was using your software all day to perform 12 repetitive tasks, Id expect the option for keyboard navigation, it might make the repetitive nature of the work a bit easier to sit through.

Assuming the jobs aren't new, what are users doing now?

You might think this a strange thing to ask, but seriously:

  • Have you tested even a prototype interface with real users of the system to see exactly how they would interact with it?
  • Have you done a comparison to the other tools they use for the their jobs?
  • Is there a minimum benchmark for functionality your software should be aiming for?
  • Is the new software better than what its replacing?

Your issue really sounds like a project management one

If your first release is going to be just a pilot with a few users you might get away with dropping the keyboard navigation. Similarly if your first release is just the beginning of an iterative rolling release schedule where you can gather and respond to user feedback and issues quickly.

If your project is like many of the projects Ive worked on recently, there are months if not years between releases (another than maintenance or patches), and as soon as the product launches all funds for ongoing development start to dry up.

Cutting the functionality from your first release might save you some time and money now, but in the long run will that still be the case? I can't answer that part for you...

{ Oh my, think of the $$$ I could make if I could :) }

  • There is no legal requirement to be devide independent. I have often wondered whether someone in the USA—the land of lawsuits—would manage to win in court by claiming repetitive stress injury that could have been avoided or mitigated by having a choice of input devices. But that's not an issue in the current case. Cost is an issue, though. As you note, the short-term savings to the project may well be outweighed by the long-term usage costs. It's impossible for me to asses the opportunity costs, from where I sit, so I can't say, either way.
    – JeromeR
    Jun 4, 2010 at 4:24

I like Jon W's answer, but I would also like to add a little bit. Are these tasks going to involve entering data into text fields? If so, then I have always found keyboard navigation vital for repetitive tasks. For an individual action, keyboard vs. mouse may or may not have a significant speed advantage, but if the user is constantly typing and then having to go to the mouse to go to the next step each time, it is going to be much more time consuming overall, since every time a user moves their hand to the mouse and back to the keyboard is additional time wasted.

Another thing to consider with this is the fatigue of constant input device switching. It may not seem like much, but if a user is constantly going back and forth between keyboard and mouse for eight hours a day, it can become very tiring.

  • That's a "Yes," on entering data into text fields. Time on task is critical, since every second costs thousands of dollars when multiplied by the number of users.
    – JeromeR
    Jun 4, 2010 at 4:19
  • Then you definitely want keyboard navigation - no doubt about it.
    – Charles Boyung
    Jun 8, 2010 at 3:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.