Practical .NET

Leveraging User Mental Models To Create Effective User Interfaces

The principles of great UI design start from a different place than the principles that lead to great application design. They both end up in exactly the same place, though.

• By Peter Vogel
• 07/18/2014

Admit it: If your room is cold and the thermostat is set to the higher temperature you want, you turn the thermostat up higher, don't you? We do that because we all have this mental model of thermostats that's organized around "achievement" -- we believe if we just ask our furnace to do a little more than we want, then the furnace will get us to what we want, faster. It's the same mental model your boss uses when giving you an impossible ("stretch") deadline: An impossible deadline will cause you to work harder and, perhaps, meet the real deadline that your boss is keeping from you.

The Way Things Work
But that's not the way your thermostat actually works (and it's probably not the way you work, either, but your boss doesn't know it). Your thermostat turns the furnace on and leaves it on until the desired temperature is reached … and then your thermostat gives up completely, shutting the furnace off. The thermostat doesn't get the furnace to work harder to get to a temperature, it just gets the furnace to work longer. Setting the thermostat higher doesn't get you to the temperature you want any faster. In our heart of hearts we know that, of course, but we set the temperature higher, anyway. (Having said that: I do understand that there was a model of Cadillacs that did work that way so that, as you got closer to the desired temperature, the fan blowing hot air slowed down. But that was the exception, rather than the rule, so please don't bring it up in the comments. Please).

Now let's look at your calendar. How do you think of your schedule? Do you think of it as an ordered list of events? Or, as most people do, do you think of your schedule as a set of buckets (Monday, Tuesday, Wednesday and so on) with a limited number of slots (9:00, 9:30, 10:00 and so on) that can be filled? Under the hood, of course, Outlook probably does maintain your calendar as an ordered list of events (which is why you can have two events scheduled for the same time) … but that's not how you, or most other people, think of it. You probably have Outlook configured to display your schedule using the bucket/slot model, for example.

One final example: We probably think of the dials on our refrigerators controlling the "coldness" of the refrigerator gets when, in fact, the dials on the refrigerator control how much heat is removed from the refrigerator. These discrepancies between our understanding and what's actually happening aren't always a problem -- the disconnect between our mental model for our refrigerator and the underlying mechanism falls into a "no harm, no foul" zone, for example.

However, Don Norman, in his wonderful book, "The Design of Everyday Things," talks about trying to control his refrigerator freezer's temperature when the disconnect did matter. The refrigerator had two dials and Norman assumed that one dial controlled the coldness of the main part of the refrigerator while the other dial controlled the coldness of the freezer. He was unable to set the internal temperature of the freezer to what he wanted until he realized that he had misunderstood how the dials worked. It turned out that one dial controlled the overall temperature of the refrigerator and the other dial controlled how that cold was distributed between the freezer and the main body of the refrigerator. With that new mental model, Norman was finally able to manage his refrigerator's temperature. Or he bought a refrigerator that matched his mental model … I forget which.

Matching Models … and Failing
Obviously, then, an application's mental model and the user's mental model have to reach some understanding -- though, as Outlook and the "no harm, no foul" model for managing refrigerators demonstrate, the two don't have to be identical. But, as I've suggested in previous columns, it all depends on who your users are. There are no hard and fast rules in UI design.

For example, do you think of your stove has having a central heating source that you can direct to one place or another (burners, oven)? Probably not. But if you own an Aga cooker, you're going to run into real problems if you don't think that way, because more or less, that's how an Aga cooker works.

And don't make the mistake of thinking these examples are unrelated to programming: as a developer, you deal with the mental models of your users all the time. For example, you have the tables in your database set up to support referential integrity, which means, for example, that you must add a row to your SalesOrderHeader table before you can add a row to your SalesOrderDetail table. However, customers probably think of the things they want to buy (the SalesOrderDetail rows) before thinking about how they want to have the order delivered (the SalesOrderHeader row). Building an application that asks the user to supply delivery information first and then trying to justify that design to the user by referring to "referential integrity" isn't going to work (don't ask how I know this). You'll have to write the application to make the user's mental model work: details first, headers later.

And if you don't get the user's mental model right, bad things happen to good companies. I worked for a company that made specialty rubber. We were, effectively, in the wallpaper business: When you run out of wallpaper halfway through a room, you don't go back to buy "more wallpaper" -- you go back and buy more of the same design. You probably go back to the store you got the first batch from and even try to get more wallpaper from the same dye lot as your original wallpaper. That was the mental model my company's customers followed and our systems were set up to support that mental model.

My company got bought by another company that made commodity rubber: It was more like selling screws than wallpaper. When you run out of screws you don't need an exact match of the screws you used before; to buy more, you probably go to the most convenient hardware store available to you. That was the mental model of its customers and that's what the company's applications were set up to support.

My company switched over to the new company's software systems and it was a nightmare. Our existing customers would call up, looking for more rubber from a specific batch of rubber. To find that batch, our users were reduced to scrolling through manufacturing records trying to find the batch and then correlating that manufacturing information with inventory records in order to find where that batch was stored. And while our users did that, our customers waited (impatiently) on the phone.

Why Designing Interfaces Matter
The user mental model might mean that writing a single application may not be possible. If you're designing a service to help people go to a movie, there are at least two different mental models you'd need to consider. If you're supporting a movie fanatic, you need to support searching out specific movies and making plans about how to see that movie -- perhaps even travelling to another city to do so. Or you could be supporting casual viewers: someone who decides to go out to see a movie and then checks to see what's available. These two different mental models are going to require two different applications.

And it's not just your users that affect your interface: It also depends on your users' stories. When I was talking about your calendar and asserting that you think of it as a set of buckets and not as an ordered list, there was probably a voice in your head saying, "Wait a minute! Sometimes I do think of my schedule as an ordered list: `I have to do this, then I have to do this, then I have ….'" And that's true: In the short run (the "what do I have to do now" user story), you do often think of your schedule as an ordered list of events you have to work through.

All of this is why, of course, Outlook allows you to look at your schedule as a list of events and why you sometimes use that facility. You can see why Norman's book was originally called "The Psychology of Everyday Things."

What You Do (and Don't) Need to Do
So, once again, I'm asking you to crawl inside the head of your personas, this time to understand how your users think about the problem you're trying to help them with. Your job is to decide how your UI will express that mental model to your users.

You're free, of course, to present your users with a newer, better mental model for dealing with the problem (like Norman's refrigerator). If you do, your job is to make that model clear to your users in your UI and, in addition, have your UI demonstrate a compelling case for why your user should change their mental model. Norman's refrigerator did neither.

In all probability, there will be discrepancies between the way your UI presents the problem and the way your application "actually" works. Your next job is to bridge that gap with code.

But as a programmer, that's what you should be doing anyway: The "I" and "D" of the SOLID code maxims refer to the Interface Segregation and Dependency Inversion principles. Taken together, one way of looking at these two principles is that the interfaces our classes expose should be designed for the client that uses those classes. Our class interfaces should express the way the client wants to work and to simplify the client's life. The interface should not be a simple expression of the underlying algorithms or table structures that the class encapsulates.

So it really doesn't matter if you're designing a UI or a class interface: You design to make life easier for the client and to match the way that clients want to solve their problems. Your underlying algorithm may work in an entirely different way … but that doesn't matter. You write your code to translate between the appearance and the reality. That's your job.

Hey, we're programmers! We can make anything work.