What are Mental Models in UX Design and Software Testing

If you are unfamiliar with the concept of mental models UX, and you work in software testing, UX design, or technology in general, understanding what this means and how to use it will help you to become a better digital professional.

Picture this scenario. You’ve just been given a new mobile phone, it’s one that you’ve never used before and has a newly released operating system. You’re young and relatively tech-savvy and know how mobile phones and touchscreen devices work, so you eagerly unbox the phone. It fits perfectly in your hand as you admire the smooth metallic finish and glossy design. You locate a little raised button on the side and push your thumb into it. The device powers up, the screen lights ambient white, and a small spinner icon appears for about a second. A little jingle sings from the phone’s hidden speakers, and just like that, it’s ready to use.

So do you now reach for the 50-page instruction manual? Or do you just start tapping, swiping, and playing with the phone? Chances are you start playing with the phone and can use it relatively well despite never having used that model or operating system before. The fact that you could switch on the phone in the first place indicates that you had already made some assumptions. You navigated through the phone’s various screens and could use certain hand gestures to get around. This suggests you already had something of a flowchart in your mind that mapped out how you thought the device would work based on your previous experience.

Why do testers need to understand the concept of mental models?

The flow I just described is essentially a mental model. Below, I outline some things you need to know and articulate others that you probably already intuitively know but have not spent too much considering.

It’s necessary to have a strong understanding of mental models, then apply them to various aspects of software design and testing. This is, so we analyze our own assumptions, work through the features that we’re designing into our products with more care, and better understand our users’ mindsets. Let’s begin…

As a young designer, fresh into the industry, I stumbled upon a book called The Design of Everyday Things by Don Norman, and it blew open my mind. My background in graphic design and illustration meant my primary focus was on how things looked. I had compartmentalized design and development, visual aesthetics, and functional or technical development into two separate boxes, thinking they only had to overlap when necessary. My first job had a design team and a development team on different floors, which did nothing to dispel the siloed approach from my mind.

One team focused on how the thing looked, such as the user interface, logos, branding, icons, etc. The other concentrated on making the product work (the back-end code, building systems, and software testing). I’ve not worked for the company I refer to for more than a decade now. I’ve been told things changed after they realized the need for ‘design thinking’ and interdisciplinary teams. This way of thinking and practice exists in many forms today. Software testers often test only whether a unit or feature “ticks the box” and works “as expected.” If the assumptions and mental models of real users continue to be overlooked, features, and software that fail to meet user expectations and usability needs will continue to be produced.

Mental models in everyday life

You’ll undoubtedly recognize the example I gave at the start of this article. All of us have mental models for everything that inform our way of making sense of the world.

Some of these have been carried over from our earlier experiences with tech, so understanding What the QA Tester can Learn from Retro UI Design can be instructive in how we approach mental models today.

Mental models are essentially assumptions of how we expect things to work when we interact with them. We don’t need to know exactly how a car engine works, but we know (and can assume enough from just looking at it and a rudimentary interaction) that the steering wheel changes the direction of the car. And we know that the accelerator pedal makes the car go faster the more pressure you apply with your foot. The car seat’s shape also suggests that it is for one person, and the seat’s proximity to the controls indicates they are to be manipulated while sitting in the seat driving.

The simplest “real world” mental model example I can think of is a door.

mental models

You know it needs to open one way or another for you to pass through it, and based on the design of the user interface – in this case, the door handle – you would know whether it was a push or pull door. Now I mention doors because interacting with them is incredibly simple. The feedback is immediate, but you would not believe the number of times we get it wrong. We might feel silly when we accidentally push into a pull door or tug helplessly on the handle, but the door won’t open. We feel silly because we blame ourselves for making a mistake, but it was the door’s designer who made the original mistake.

If a customer or user makes a mistake while using your product, the mistake is yours as the product designer.

Using the door example, there were two options available to the users’ mental model – either push or pull. Upon viewing the “user interface” (seeing a curved metal handle that the user can grasp with their hand), their mental model flowchart progressed down to the ‘pull’ option – a natural conclusion. Because the door designer chose to attach the same pullable metal handle to both sides of the door, the user made an incorrect assumption, so fruitlessly yanked at the door handle and subsequently turned an embarrassing shade of red. This whole episode was the fault of the poorly designed UI, which resulted in a poor user experience.

Good design is invisible

How often do you remember using a door? Hardly ever, right? It’s when things go wrong, and you crash into one that you remember. That’s because good design is invisible. Returning to Don Norman, the author as mentioned earlier who first got me thinking of this,

“Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible, serving us without drawing attention to itself. Bad design, on the other hand, screams out its inadequacies, making itself very noticeable.”

And this leads me to the next section, taking it into our work.

Mental models in UX design and software testing

When developing new systems, design interfaces, and trying to solve new problems, we should always build on user assumptions and challenge ourselves. We should always try to innovate and be aware that we are not working in unchartered territory. Everyone will have some idea about how things should work, even at a base level. Although the digital world is relatively new, it has already established a UI and UX heritage, meaning people expect certain conventions to exist.

So, just because we as software testers and designers assume our audience will “just get it” because we’ve designed it to work that way, user assumptions might mean that it’s not necessarily so. I’m sure the designer of that annoying door I mentioned earlier just assumed people would use it ‘correctly,’ so didn’t consider both sides.

In UI design and UX theory, many conventions already align well with people’s existing mental models. There are some areas where we can push a little bit and explore more innovative ways of communicating interaction. Others should be left well alone except to make them work as best they can in the context of the digital product we’re creating. Some standard UI elements include:

Links – these are expected to be underlined and/or set in different colored text.
Buttons – these will appear in a colored box or have a boundary sear that indicates this is clickable, and the space around it is not.
Content – the wording is structured and presented as we expect them from books, and we can navigate content through pagination, bookmarking, and scrolling/
swiping
Search – this feature will usually appear in a rectangle box and appear in the upper right corner of the interface or website
Logo – this will be positioned in the top left of the application and will usually take you back to the starting point of the application (or ‘home’)
Navigation – this will usually appear at the top of the screen or left-hand side of the application. It will be a combination of textual links and icons that indicate the area or the action to be taken. If the navigation is deep or complex, a breadcrumb trail is expected so the users can know where they are in their navigation journey.
Manipulating and adjusting – elements in the user’s direct control will have a visual indicator, textural, or graphic that suggests a tactile quality. Like a handle or ridged design that one might expect to manipulate with their finger if in the ‘real world.’

These are some visual and user interface related mental models and assumptions, which are vital to helping our users interact with our digital products. And it’s essential to consider some user experience mental models that may be a little more abstract, layered, or indirect. These may include:

Archived or deleted items – it is expected that archived items will be moved to a different area such as a bin or trash can and retrieved at a future date if required. However, if files are to be removed permanently, a notification must be shown.
Alerts and notification – these prompts are expected to appear when carrying out necessary or consequential actions. They either warn the user of the potential consequence or inform them of the action’s success or failure. We must be conscious of the frequency of notifications. If users are alerted too often, they tend to tune them out and risk ignoring important ones.
Undoing – users may expect to be able to undo certain actions, such as moving an item from one box to another, in much the same way as in real life. In contrast, it may not be possible to undo some actions, but the user may expect to have the facility to overwrite with relative ease an incorrect or out-of-date value with a new one.
Progression and saving – these days, people expect actions to be automatically (and often instantly) saved. We feel we can pick up where we left off and close down or exit an application at any moment. If this is not the case, progress must be visually displayed, and exit notifications must warn the users of the consequences of not actively saving.

Conclusion

So, when software testing, ask not only “does this feature work as expected in the brief,” but “does it meet the expected mental models that I have.” Ask, is it intuitive for me, and finally, “will it meet the mental models of other users” – just because I know how it should work, will others?