(Click here to link to the Russian version.)

Dear Tog,

I have seen people getting computer literate within 2 months up to a point where they started writing applications and macros. On the other hand I have seen people whose progress stalled at a very early stage and who constantly have problems solving their tasks with the computer. So why is it that people with about the same educational background turn out so differently when it comes to computing?

To me, there are mainly two reasons for that:

1. The GUI of an operating system or of application software is usually not "intuitive" for a novice user. He or she will always have to learn.
2. As in all learning processes, motivational factors are a major key for success.

The word "intuitive", in my opinion, is the most harmful and misleading word in User Interface Design because it creates the expectancy that anybody could use any function of any piece of software "out of the blue". Reality shows that this is not true. First you have to learn the underlying metaphor with all its objects, relationships and limitations. Then you have to learn interaction techniques: moving the mouse, double-clicking, dragging-and-dropping. Then you have to be able to formulate your task, check if you can accomplish the task with the software and transform your intentions into actions. And let's not forget that you have to learn to interpret the output that your actions create...especially error recovery.

This list obviously is not complete. The point I want to make is that there is still a lot a user has to learn before he can interact with a computer in a way that satisfies his goals - even in 1998. I think that generally the mindsets of novice users have not changed dramatically. There still seems to be the same mix of people who feel in control and are ready to explore things and people who are anxious and intimidated by computers. The latter are usually not able to generalize interaction techniques across applications and always tend to stick to a very narrow path while interacting with the software. I have seen one person that had a whole stack of "cookbook recipes" on how to operate his software. Three of them dealt with opening files in Word, Excel and PowerPoint. In Word and Excel he used the File...Open menu. In Powerpoint his recipe told him to use the "Open File" button on the toolbar because that's the way someone had explained it to him. He never had gotten the idea that "File...Open" on the PowerPoint main menu would do the same as in Word and Excel.

Since I believe that exploring software is very important for novice users I think that user interface designers as well as software engineers should take one of the most neglected user interface design guidelines very serious: error tolerance. I think that this is one of the things that can make users feel in control of their environment and give them the needed courage to try out things "off the beaten path". Maybe this would help to make more people as sophisticated as they want to be...

Greetings and best wishes,

Jens

Jens Nagel
Human Factors Engineer
Mannesmann Autocom
Duesseldorf, Germany.

I would disagree that engineers are not building software with much error tolerance. Compared to the "bad old days," today's better GUI software shows remarkable tolerance. Web software tends to not display as much, which is more the fault of today's primitive browser technology, rather than any lack of desire or competence on the part of designers and engineers.

On the myth of the "intuitive" interface, however, I couldn't agree more. "Intuitive" is a double misnomer. First, software is quite incapable of intuition. At the most it can be "intuitable." And it is not that, either. Jef Raskin, the Father of the Macintosh, demonstrated rather eloquently in his article, "Intuitive Equals Familiar" (Communications of the ACM. 37:9, September 1994, pg. 17.), that when people say "intuitive," they are really talking "familiar."

Even familiar is often a goal that proves unobtainable. When designing icons, for example, I always strive for instant recognition--familiar--but I'm usually content if I can achieve memorable. True, I will have to teach people the first time, via a tool-tip or other means, what the icons stands for, but if they will remember that meaning from then on, that can be considered a success.

How does that scale up? If there are 1400 icons and 1200 pull-down menus and 8700 dialogs, as found in certain software I won't mention, how can software appear either familiar or memorable?

The answer lies in developing a few clear, powerful concepts, embodying them in a familiar, communicative metaphor and then, most importantly, teaching the metaphor.

When Bill Atkinson was developing HyperCard at Apple, he kept trying to explain to us how all these objects on the screen could be laid out and tied together. It just didn't make sense. Then he drew it. It was a layering system, with objects having behavioral and visual layers lying on cards that had behavioral and visual layers. Once you saw the picture, even for a few seconds, you understood the very essence of HyperCard and could pretty much predict your way through the balance of the learning experience. This one simple illustration eventually became the lead-in to the manual, eliminating the need for an enormous volume of words that kinda-sorta explained the concept.

Which leads me to my final point: concepts are not a function of the intellectual part of the brain. Concept are born and grasped through intuition. So in a sense, there is such a thing as an intuitive interface if, as Jef Raskin suggests, we look beyond the form of the word. Good metaphors tend to arise from the designer's intuition. When transmitted effectively through the visual and behavioral design of the program, users will be able to reconstruct the driving principles the designer wanted to communicate.

Guidelines for quick-to-learn software:

1. Strive to make it familiar
2. Do make it memorable
3. Build your design on a few, simple, driving concepts
4. Communicate those concepts through one or a few powerful metaphors
5. Test your prototype and figure out whether people are "getting it."
6. If people aren't, either change your design or develop training materials, such as a few simple drawings, that will succeed in communicating the idea.

If you do all that, your only worry will be second release. As software matures, it tends to get encrusted with myriad new features that can turn even the smoothest original design into a motley mass of sharpened barnacles.

Microsoft Word's interface reflects its history as much as its capabilities, with each new capability appearing as a mode, rather than being integrated into a single whole. Adobe Photoshop has needed the concept of objects for many generations of the program. Its underpinnings, however, will only allow layers, and serious Photoshop users are losing control of their own drawings. It is not the developer's fault. Today's systems do not allow us to detach the metaphor and design sufficiently from the underpinnings of the software to allow us to re-smooth our interfaces as we add new features and capabilities. An important research task for the coming decade will be to figure out how.

tog