There is lots of knowledge about software user interfaces -- standards, models, experts and the all rest. But there's a problem: there is no difference, the way things are now, between designing a UI for someone using a piece of software for the first time, and someone who uses it over and over. This results in astounding waste of time for the heavy users of software. It's long since time to fix this glaring hole in UI theory!
Most UI’s are built to optimize the initial experience of the person using it. The assumption is made that the person is using the software for the first time and needs to have a good experience. Otherwise the user will reject the software, not use it again, and it might feel bad! So the software needs to be “user-friendly.”
But what if the people using the software use it for a good part of the day, every day? If we can make them just 10% more efficient, then that’s worth something. So what if they need some training at the beginning? And the fact is, in many cases we’re looking at way more than 10% improvement. In large categories improvements of 50% are available, and in some large-scale cases, substantial whole-number factors of gain.
Since everyone thinks they know how to build user-friendly software (if only more of it were!) and since most programmers don’t even think about high-use, high-productivity software, here are the main principles of building a user interface whose users will spend a great deal of time using, and who want to get more done in less time:
- Arrange the work to minimize movement
- The first and most important step is to eliminate is anything that takes the human’s eyes or hands away from the computer. Paper is a prime example – having an image of paper on the screen is vastly more productive than having a physical paper.
- Given that eyes and hands are on the computer, the next step is to eliminate the use of the slow input device – the mouse or touch pad. Everyone loves the mouse. They think requiring its use is the most user-friendly thing you can do. But we’re talking about productivity here, and in any productivity race between mouse and keyboard, the mouse is a sad, distant last. So with the possible exception of logging in and out, just lose the mouse. Don’t compromise or be “nice” about it.
- Now that all inputs are keyboard inputs (and they are, aren’t they???), reduce the number of keystrokes to the bare minimum. You would be amazed, when you count keystrokes (yes, you should actually count keystrokes; yes, you), how many can be eliminated in the average application.
- Finally – don’t laugh – minimize eye movement. It’s not the time, it’s the attention.
- Arrange the work to minimize thought.
- Sometimes, like when people are writing something, they just need to think. That’s OK.
- But any other kind of thinking is just a waste of time. Think about your own thought-free actions; I hope typing is a good example. When you have to look at the keyboard or think about it at all, instead of just typing, what happens to your rate of typing? Does it improve as a result of the thought? I didn’t think so.
- If some training is needed at the beginning – OK; if training is needed on an on-going basis, you are probably making the user do things the computer should do – instead of training, automate.
- Embodying domain knowledge is really tempting. You should make your system so that the users don’t need domain knowledge. It’s made particularly hard because you typically need domain experts at the beginning to make sure your system is sensible. They want to see the way they think about the problem embodied in the system.
- A good example is working with health care forms. There is a huge amount of domain knowledge involved in doing this right. But the vast majority of this knowledge can be put into the system, so that the people end up just doing things that only people can do.
- Arranging the UI and the people so they know what they’re doing and why is really tempting – resist that temptation! The more your users just do their work, focusing just on productivity and accuracy, leaving the rest to the “system,” the better off everyone will be.
- A prime example of this is QA. In most systems, the users know whether they are doing the work for the first time or checking someone else’s work. This knowledge is built into the user roles and the queuing system. It’s true that in some cases this can’t be avoided, because of the nature of the work. But you’re well advised to avoid it, if you possibly can.
- What does role hiding look like? An example is in heads-down data entry. In the early days, experienced people would look at what was supposed to be typed, look at what was actually typed, and check for errors. It turns out that it was faster and more accurate to simply have the “checker” enter the data as though for the first time – and it always was the first time they were entering it. Then the system would compare the results, and flag an inspection or a third keying to resolve the conflict. This came to be called “blind double-key entry,” and remains the gold standard for productivity and quality in the industry.
- Why does role hiding work? When someone knows what someone else thought the outcome or result should have been, it influences them, one way or another, and it takes them time. It’s like when you suspect a teacher of giving biased grades or you want to know how good a food is. You get the most objective results by giving the tests to second teacher for grading because the (anonymous) other teacher got sick (or something), or you give the food for testing without labels of any kind. Remember the famous tests of Pepsi vs. Coke? Coke drinkers would always prefer Coke when it was labeled as Coke – but when two colas were unlabeled, most would prefer Pepsi, even the Coke loyalists.
Building a UI that optimizes the productivity of the people who use it is a new and different way thinking for many software folks. But it's well worth pursuing -- the results speak for themselves, and the professionals who use the UI will appreciate being able to get their work done in less time.
Comments