A mental model, in other words, is what we believe to be true, generally based on our experiences, and how we assimilate new things into our existing knowledge. It doesn't have to be the truth, and it usually isn't. It just has to settle in our heads well enough to let us sleep at night. It has to help us understand how to use a computer and understand what it is, but not necessarily what it really does.
For users to feel good about an application, they need to feel as if they understand it. Making it as simple as possible for them to understandeven if that simple understanding is completely inaccurateis designing the obvious. Of course, the inaccurate understanding has to be useful as a way of thinking and simplifying, but as long as that's true, the design has a better chance of succeeding.
In other words, it's OK if the user is completely wrong in her perception of what is happening as long as her sense of understanding makes her feel good and competent, and she can accomplish her goals with her understanding, regardless of how faulty it might be.
An implementation model, on the other hand, is something that has been designed, usually by not being "designed" at all, to reflect the underlying details of a system. Implementation models have no regard for a system's users. They aim, usually, to please the geeks that create them.
That old DOS prompt, which required us to understand how to forcibly remove a file from the dark shadows of the hard drive index, is an example of an implementation model. We were expected to know how the hard drive works, how to remove an item from it, and so on. Now, we just throw the darn thing away.
In Web applications, many implementation-model designs appear even when there are far better ways to represent the functionality the interface elements are intended to handle. This chapter is about how to avoid implementation models and design interfaces that make sense to users without forcing them to understand the underlying technologies.