Watching people in usability tests is fascinating. Anyone who has done this will know what I mean. Months of planning a system, of hours spent building in impecable logic are dashed irrefutably against the rocks of reality when user after user simply fails to see it the way the designer does.
The concept of mental models was first put forward by Scottish psychologist Kenneth Craik in 1943. The idea is that humans are frantic interpreters and, to aid in the speed of interpretation, will create small scale pictures in their mind of what is going on. While these models continue to perform users will hold on to them and use them. But they are expendable. If the user hits a brick wall and their model fails to predict what happens in the real world, it will be abandoned for a new one. Philip Johnson-Laird extended this concept through studying how readers understood novels, saying that some authors would force the reader – through ambiguity – into holding several mental models in mind concurrently – each vying for selection.
In designing computer interfaces, we often have conceptual models (to a certain extent, the designer’s mental model, or the shared “mental model” of the design team), and of course there is also a functional model -what actually happens, how it actually works. Something that doesn’t get mentioned in HCI discussions is that there are very often business rules which also apply throughout the function, which are essentially part of the functional model. We need to work hard to try and get the often complex functional models to deliver simple, understandable conceptual models.
So take a new site where items can be added to a basket by drag-and-drop. There’s a number of models being combined here. The user is being asked to co-opt an understanding taken from the classic operating system GUIs (dragging and dropping). There is an underlying co-opting of the supermarket experience of baskets. I, for one, am not convinced that this later abstraction was a natural one to users to learn, although most users do now understand the concept of an electronic basket almost as well as they know how to shop in stores. Of course the functional model will be completely different and much more complicated.
It is suggested in this fascinating summary that conceptual models shouldn’t obfuscate what is really going on. Certainly in terms of HCI, I find that view insupportable. The user doesn’t want to know that their product going into the basket is just a new entry in a database join table having passed through a set of business rules. Although we do see sites regularly forcing customers into this level of mental gymnastics.
Sometimes, resembling other mental models is helpful (drag-and-drop in the example above). Often too, it is confusing. Picking only parts of a conceptual framework, or attempting to abstract it too far from its original purpose leads to a cognitive disonance that leaves the user unconfident, often taking them back to square one.