Implementation, Mental and Representation Models in User Experience

One of the main goals of great user experience (UX) design is to make your product easy and pleasurable to use. To achieve that, UX designers use a number of different approaches which share a common goal: making the product easy and pleasurable to use.

So, to put it simply, all we need to do is to find what will make the product easy to use and implement it. That’s where models are useful.

Models are more or less abstract representations of how things work. They are our best shots at trying to understand often complex behaviours and processes. They are our tools to help us understand them.

Bad User eXperience

Bad User eXperience

In user experience design, interaction design and in human-computer interaction in general, three model types are especially important:

  • Implementation models,
  • Mental models, and
  • Representational models.

Implementation models

An implementation model is a representation of how a system (application, service, interface etc.) actually works. It’s often described with system diagrams and pseudo code, and later translated into real code.

An implementation model answers the question “How does this work?” and is in fact a description of the way in which a developer will build the system, app or whatever. The reason why teams without user experience support often have extremely poorly designed software for users is exactly because the implementation model is reflected in every interface element.

Implementation models

It’s easy to design software like this, and if you see an interface with dozens of buttons on the screens, one for each implemented function, chances are you are looking at a system that was designed according to its implementation model.

Granted, we will have an (almost) perfect translation between the system functionalities and the user interface, but real users will suffer.

User interfaces designed by developers generally follow the implementation model, their user interface is mapped to the program’s functions. The problem? Real users don’t feel good using interfaces like this.

Users don’t care how the developer made the system work. They have their own ideas about what is happening when they interact with the system. Interfaces which do not respect this can be very difficult to use.

Mental models

Mental models answer the question “How do users think this works?”

Mental models have been studied for years. While they might appear to be novel, the fact is that they appeared for the first time back in 1943 in the book “The Nature of Explanation” by Kenneth Craik.

Cognitive science is especially interested in exploring and understanding mental models since they are representations of the way that users perceive external environments and realities. It’s often said that a mental model is a set of beliefs about how a system works and how people interact with that system based on their beliefs.

Those beliefs, for the average user, are not coherent and are not even remotely similar to the implementation models used by application developers. It is this gap between the developer’s logic and the users’ perception of things that leads to frustration.

This is why interfaces should be closely related to users’ expectations and beliefs about how the system will work and behave. User interfaces must represent users’ mental models and the mental model must be the one that is used as a guide when we are designing user experiences.

But, on its own, a mental model is not enough. It doesn’t help the programmer code the system or the visual designer bring it to life. For this reason we need a third model, the representation or design model.

Representation models

This model answers the question “How is this presented to the user?”

Representation models are directly related to the user interface itself, to the layer of interaction between the system and the user. It’s rarely (thankfully!) a direct representation of the implementation model, it’s more often a designer’s view of users’ expected mental models.

The wonderful thing about digital systems is that the face of the application can be quite different from what is going on inside the machine. Think about the leap from text-based computer systems to the graphical user interfaces we know today. Suddenly, instead of memorising lists of commands, all people had to do was click on a picture of what they wanted.

Designers must be closely familiar with users’ mental models to be able to craft great representation models. It will be beneficial for them to know the basics of the implementation model, at least parts of it, but it is critical to understand and map properly users’ expectations, their mental models and to create an interface that is coherent with those expectations, not with the actual implementation.

If, for example, buying something from a web shop requires a number of transactions and complex operations in the background, those should be hidden from end users. For them it is just the process of clicking on an item and adding it to the shopping cart. The designer must create a user interface that represents that mental model and that will lead to the creation of great user experience in which the system will behave exactly as users expect.

So, can I write crappy code?

So if the implementation model is hidden from the eyes of most users, does it even matter? Well, if we assume that a crappy implementation model is in fact based on bad coding practices, lack of optimization and an unstable architecture, then we can only expect a bad user experience. Because the user experience is not only about mental models and their representation, it’s also about the layer that powers the whole experience.

In a great implementation model, code is well-written, highly optimized, tested and created following a host of other good practices that help ensure a system is reliable, responsive, scalable and all the other things we need for it to be worth the money we invest in it.

While these qualities might not be the most visible, if the backend is not created with proper care users really feel it. The consequences of a bad implementation model are as damaging to the end user experience as a poor understanding of users’ mental models and as badly designed representation models.

So, write great code, but keep it hidden. Create great user interfaces which reflect users’ expectations and needs and you will have happy, satisfied and loyal customers!

Share your experience with us...

Comments (4)

  1. How do we uncover these models? how can we add physical significance to these models?
    For example a wire frame might take care of the Representative model, may be high fidelity html prototypes can be counted as implementation models.

  2. Can you please cite your sources? Many ideas here come from the book “About Face 2.0″ by Alan Cooper and Robert Reimann.

  3. Very interesting idea to talk about these three models, but the article was too vague. I’m not a developed, just a graphic designer trying to learn more about UI, and the closest we got to a concrete example between the difference between an implementation model and a mental model was shoing the complex processes behind a transaction versus clicking to add to a shopping cart. I wasn’t able to gain any concrete understanding through this article, and there was no real reason given for why you still shouldn’t write crappy code. You said “If you write crappy code the users can really feel it.” Feel it how? What are the damaging consequences of poor (though I’m assuming still functioning) code? I think this is an interesting topic and would have appreciated more examples of that mismatch between implementation, representation and mental models.

  4. I would like to share some more information with you about some models. I would like to mention that the user model is also a great model for creating human computer systems. The challenge in an information-rich world is not only to make information available to people at any time, at any place and in any form, but to reduce information overload by making information relevant to the task-at-hand and to the assumed background knowledge of the users. User-modeling techniques can effectively support learning on demand by helping users to identify opportunities to learn additional functionality relevant to their task at hand and to avoid people becoming stuck on suboptimal plateau.

    Other domains comparable to the user modeling are:

    1. Software reuse (complex systems develop faster if they can build on stable subsystems)

    To reduce the complexity we can also make use of domain-oriented subsystems. They can have their won templates, forms and associated wizards. Domain-oriented design environments integrate a number of components relevant to user modeling. They provide specification components that allow users to enrich the description of their tasks.

    2. Organizational memories and organizational learning

    I also like to mention that there is also a difference between developing some systems like an automated teller machines or a high-functionality application (HFA). Automated teller machines are “walk-up-and-use” systems, are examples of low-threshold, low-ceiling systems. They should be easy to understand and use without prior experience. High-functionality applications (MS-Office, Photoshop) are systems that are difficult to use at the first time but it will change over time.

    HFAs are broad, and users do not know about all of the software features that could help them in principle and in some tasks that they may never attempt. In any HFA, there are functions for tasks that are used too infrequently
    by users to make it worthwhile for them to learn them and complex enough that they need to relearn how to perform them each time they try to accomplish the task. Most users do not want to become technical experts by learning in the abstract a large number of functions provided by HFAs, they just want to get their tasks done.

    The design of HFAs must address three problems:
    1. The unused functionality must not get in the way
    2. Unknown existing functionality must be accessible or delivered at times when it is needed
    3. Commonly used functionality should be not too difficult to be learned, used, and remembered

    I agree what you said that “experts” (users who know everything about a system) no longer exist in HFAs. In HFAs, being an “expert” is at best an attribute of a specific context, rather than a personal attribute. HFAs create challenging learning problems that are representative for numerous complex systems.

    HCI is to address the problem that systems will be unable to interact with users cooperatively unless they have some means of finding out what the user really knows and does.

Trackbacks

  1. Pingback: Designing according to implementation models and why you should think twice about it | Jess Writes Words