Interface Models

Alan Cooper, in his superb book About Face: The Essentials of User Interface Design, describes the way users think about systems (and the way systems think about users) in terms of three models: the mental model, the manifest model, and the implementation model. These three different ways of thinking about systems are useful tools for making decisions about the design of your application's user interface.

A user's mental model describes what the user thinks is happening. This doesn't often match what's really happening, but that's OK. I have a vague notion that my body "burns" food to provide me energy in the same way that an automobile engine burns gasoline. I do know that the processes are really quite different, but I don't care. I have to put gasoline in my car to keep it running and food in my body to keep it running. My mental model is perfectly adequate to get on with things.

The same is true of computer systems. Whether I'm using a typewriter or a word processor, if I hit a character key, a character appears. The mental model is the same. What's actually happening, of course, is quite different. What actually happens is the implementation model. All that behind-the-scenes stuff about pulling levers or running code is part of the implementation. Users don't care, and shouldn't be forced to.

The user interface is the manifest model that sits between a user's mental model and the developer's implementation model. It is, if you will, the model of the process that the system reveals (manifests) to the user. Your goal in designing an interface is to hide as many details of the implementation model as possible. The ideal system exactly matches the users' mental model. It won't often be possible to match the mental model of the process exactly. But the closer you can get, the better.

If you're interested enough in computers to be reading this book, your mental model won't match the users' mental model. My mental model of using a word processor is that I hit a character key and an ASCII code is stored in RAM somewhere. This isn't very close to the implementation model, but it doesn't resemble what the average clerical worker thinks is happening either.

This is the great danger of designing interfaces: even if you aren't directly involved in the implementation, you almost certainly will know something about it. You have to either develop a knack for temporarily forgetting the implementation details or ask a user guinea pig to provide you with his mental model.

The best practice is to conduct formal usability tests using a prototype of the system. Although this is rarely possible, any kind of usability research is worthwhile. If you've built a prototype, find a few users and have them play with it. Ask them what they think is going on. You'll get some surprises. If you haven't built a prototype, you can ask about a similar system or even use a paper mock-up. I haven't had a lot of success with this last technique, however. I've found that users get confused between an interactive screen and a report when both are presented on paper.

When you've gathered as much information as you can, think about where the implementation model (what's really going on) is intruding on the users' mental model, and then resolve those areas. Are you using the wrong terminology? Always use the words the users use. Are you forcing users to think about "editing records" when what they want to think about is "changing addresses?" This could be a terminology problem, or it could be a problem in the system structure, which we'll look at in the next chapter.