Conceptual Models

A good conceptual model is one in which the user's understanding of how something works corresponds to the way it actually works. This allows the user to confidently predict the effect of his actions. As Norman states, "This requires that the principles of operation be observable, that all actions be consistent with the conceptual model, and that the visible parts of the device reflect the current state of the device in a way consistent with that model."

There are three different conceptual models involved in this process in a program's user interface:

• The design model The conceptual model created by the user interface designer. This model is how the user interface designer intends the user to see a program.
• The user's model The conceptual model of the user interface as understood by the user.
• The system image The visible user interface that the user observes to form the user's model. This image can be different from how the software is actually implemented, which I will call the implementation model.

Ideally, the design model, the user's model, and the system image are all in agreement. When this happens, the user understands how the program works and has well-founded confidence in his ability to use it. The user can accurately predict what the program will do as the result of his actions. When this doesn't happen, the user is confused and unsure of what to do.

Notice that the user's model isn't fixed but that as the user interface designer you have no direct control over it. All you can do is create a design model that makes sense and a system image that matches the design model. You also need to do plenty of user testing on the program to make sure that users understand it. Aside from user testing, users and designers do not communicate directly except through the user interface; that is, through the program's system image.

Interestingly, these conceptual models happen whether or not you intentionally design them. The more normal your program is—the more it follows the standards and has a familiar appearance that is immediately comfortable—the less likely the design model and user's model will diverge. You'll have to worry more about this issue when you create new, nonstandard interfaces; use nonstandard controls; or include complex features.

TIP

---

Conceptual models happen whether or not you intentionally design them.

Conceptual Model Problems

To help them understand how a program works, users naturally make conceptual models based on whatever knowledge they have. Of course, that knowledge might be completely wrong. When this happens, the user becomes confused, finds the program hard to use and learn, and makes many mistakes.

I recently encountered a simple example of a conceptual model problem with my two-year-old son Philippe. I upgraded his computer to Windows 98, which had the side effect of turning on the energy saver feature. Soon I discovered that he was turning the computer on and off quite often. In the design model for Windows, the monitor is blank when

• The computer is turned off.
• The energy saver has turned on.

In my son's user model, the monitor is blank when

• The computer is turned off.
• The computer has crashed.

He has no idea what energy is or why anyone would want to save it. When he sees a blank screen, he thinks the computer needs to be reset. Although in this case he could turn the monitor on by simply pressing a key or moving the mouse, he knows there is no reason to try this if the computer is off or has crashed. By turning off the energy saver feature, I was able to make the design model agree with his user's model and the problem was solved. While this is clearly an example of a conceptual model problem, the conceptual model in question isn't necessarily bad. After all, young children are not the target user for most hardware. But this is clearly an example of how an incorrect user's model leads to confusion.

How to Choose a Design Model

Bad things happen when the design model doesn't match the user's model. An obvious question to ask is: Why bother with a design model at all? Why not make the implementation model (as I said, how the software is actually implemented) the design model? Won't this eliminate any opportunity for confusion? Perhaps—this approach could eliminate some confusion and would certainly be easier to program. But the design model is intended to hide the gory details of the raw implementation model that users don't want to see. For example, MS-DOS is a much more accurate reflection of the way computers work than Windows. Tag-based word processors are a more accurate reflection of a word-processing file than WYSIWYG editors. The problem with implementation models is that they expose too much, much more than users need to deal with to get their work done. For example, the user doesn't care which tag is used to make text bold; he just wants the text to be bold. By working at a higher level, design models make user interfaces easier to understand and use, and they help make the user more productive.

A good design model focuses on what the user needs to do and wants to understand. A good design model for a user interface

• Is focused on the user's needs.
• Is simple.
• Is easy to understand and remember.
• Hides implementation details that the user doesn't need to know.
• Makes it easy for the user to predict what the user interface will do.

It is possible that the best design model is in certain cases the implementation model. For example, system utilities typically hide little from the user. But whatever model you use, the key to success is to do plenty of user testing to make sure that users understand the model.

An Example Conceptual Model

An interesting example of a conceptual model is Windows Explorer. Windows Explorer largely matches the raw hierarchical file system, in which files are contained in folders, each of which can contain other folders and files. On the other hand, the Windows Shell Namespace makes system objects not directly related to the file system appear to be part of it. Specifically, Windows Explorer makes network drives, the Control Panel, the Recycle Bin, the Briefcase, and printers look like files and folders. Even the Microsoft Internet Explorer home page and current page are integrated into the Windows Shell Namespace. This technique gives the user common access to all these features from a single program.

Metaphors as Conceptual Models

A popular technique for conceptual models is to pattern the model after a common real-world object. This way the user can readily identify what the object is and understand how to use it. While using a metaphor can help the user grasp the conceptual model quickly, it runs the risk of having the user's model differ from the design model. The problem is that user interface metaphors rarely match the exact behavior and properties of their real-world counterparts, and in that case they can mislead the user as to what an object will do. In other words, the real-world properties of a metaphor can be counterproductive if the interface behaves differently.

A classic example of this problem is the Trash icon on the Apple Macintosh desktop. You can delete a file by dragging it to the Trash. You can also eject (but not erase) a floppy disk or CD-ROM by dragging it to the Trash. This disk-ejection technique bothers everybody, especially beginners. The real-world properties of a trashcan suggest that placing a disk in the Trash should be akin to throwing away its contents. While Apple has several reasons for this design decision, it ruins the metaphor and, conversely, the real-world properties of the metaphor ruin the program feature by making you not want to eject disks this way. Had a metaphor not been used—had the Trash been given a meaningless name like Storage Munger—there wouldn't be a problem. Of course, the real problem here isn't using a metaphor but assigning it a behavior that is counter to our common real-world experience.