Lecture 4.2: Mental Models (15:28)

In this video, we are going to talk about mental models,

and the questions that we are going to tackle here are:

“What makes an interface learnable?“ and “What leads to errors that people make in user interfaces?”

And to do that, I’d again like to start with an example from the physical world.

Here we are outside the Computer Science building at Stanford.

And what I’d like to show you is an example of a user interface error.

It’s really simple one: Our department and its front door has two doors.

It both have exactly the same handle on them. However, the door on the right never actually opens.

So, if I go to use this door right here, 24-hours-a-day 7-days-a-week it never works — it’s locked!

So why does it have the same handle as the other that does open?

And you can see right here that a whole lot of people have tried using this handle.

In fact, faculty who have been around for years

still often make the mistake of grabbing the wrong door.

This would be a whole lot better if this door had no handle here.

You could still exit — you can see this part right here —

but if want to enter, you would know where to grab and which door to use.

Let’s say you’ve got a refrigerator,

and the problem is that he freezer is too cold, but the fridge is all just right.

This refrigerator has two dials: One of them is labelled A through E,

the other is labelled with numbers, 3 through 7.

and there’s an instruction manual

that lists combinations of letters and numbers for different settings of food.

So what do we do to have the refrigerator stay the same, but the freezer to be less cold?

Well, the action is going to depend on the mental model that you have of the system:

One reasonable model that you could have is that there are two cooling units,

and there’s one dial that controls each of the units.

And, in that case, what you would want to do

is [to] figure out which of those is connected to the freezer and tweak that dial.

[It] turns out that’s not actually how it works: That there’s only one cooling unit in this refrigerator,

and then it has a splitter which controls the proportion of cold air

that goes into either the refrigerator or the freezer.

And so, if you’d like to be abe to change only one of the two chambers —

in this case: make our freezer less cold —

what you have to do is [to] move both of the dials —

dial back the total amount of coldness going into the refrigerator,

and then change the fraction

so that the fridge still gets the cold air that it needs but the freezer is getting less.

If a lot of users misunderstand the functions of these two dials and get them wrong,

then I think it’s fair to say that this is a poor user interface.

There’s a lot of ways that you could fix this.

Pause the video and think of a few of how you might make this refrigerator interface better.

Here’s a couple that I came up with:

One is if the user believes that one dial controls the fridge and the other dial controls the freezer,

you could have the functionality of the system work that way —

that you’d have two blowers, one for each.

You could also simulate two blowers, by having computation in the middle

and still have the dials connected one for each of the two.

Alternatively, if you really felt like it was essential

to have the “total cold plus changing the fraction” model,

which is probably not as good a user interface but might be needed for cost reasons,

in that way you could think of a way to have

a diagram or other kind of cue that would explain better what was going on rather than cryptic text.

In all of those cases, the goal is for the user interface to beacon to the user

what the mental model that they should think about the system with is.

And, of course, as you interact with the system more, your model becomes more sophisticated.

But there’s a big pitfall and a danger of being a designer:

You’ve spent so much time with the system that you know it works under the hood

and you how you imagine other people will think about it.

But your expertise can be crippling: The mental model that you expect users to have —

you expect it to be the same as yours — just often doesn’t pan out in practice.

And that’s one of the reasons why it’s really important to get real people who are not the designers

in front of interfaces as soon as possible —

to help you discover those differences between your mental model and theirs.

And the benefits of aligning the user and designer mental models are obvious:

Because when you have this mismatch, that can often lead to slow performance,

or errors, and frustration on the part of the user.

Where do these mental models come from? Well, that’s a fascinating question,

and one that deserves a longer answer than I can offer in this short video.

But I can say a few things to get you started:

The first is that people reason about new interfaces

by analogy to old interfaces that they’re more familiar with.

And when can leverage that — when you can figure out what people are familiar with —

and use those metaphors intentionally in the construction of new interfaces,

you’ll often be really successful.

So, for example, if you can say that a word processor is like a typewriter,

then people will transfer their believes and skills with the typewriter over to the new word processor.

The models that we build that guide our action: We have about our behaviour, of other people’s,

of objects, of software — really anything and anybody that we interact with.

But that’s not to say that everything is tidy and organized upstairs:

Our mental models are incomplete; they’re inconsistent; they change over time;

and they’re often rife with superstition.

The second thing that I’d like to talk about today

is two important different kinds of errors that are based on the user’s mental model.

The second thing that I’d like to do today is to distinguish two important categories of errors

that are based on differences in what the user’s mental model is about what they believe.

The first category is a slip.

With a slip, you have the right model of how a system works, but you just accidentally do the wrong thing.

So, if I go to reach for one button and press another — just by a motor error — that would be a slip..

On the other hand, a mistake is when I do what I intend to do,

but I have the wrong model of what I ought to do.

So, if I’m driving, and I think that I ought to take this highway exit to get [to] where I need to go,

and I take it exactly as I intend to, but I was wrong in my belief, that would be a mistake.

And, as a designer, you’ll correct these two kinds of errors — or prevent them — in your design differently.

Slips you’ll most often try to prevent by improving the ergonomics

or visual design of the user interface —

spread things out so it’s less likely that you’ll hit the wrong thing;

make targets bigger.

With mistakes, on the other hand, what you’ll need to do is [to] provide better feedback,

or make clear what the options are.

So, limit the number of mistakes that you [could] make.

You’ll want to improve the user’s ability to perceive the affordances of your software:

Make it clear to them what is possible to do.

Here we have an interface that led to a lot of user errors.

This is a ballot from Palm Beach County, Florida during the 2000 presidential election in the US.

There were two major party candidates —

the Republican candidate George Bush and the Democratic candidate Al Gore.

Across the nation they were, overall, running neck-in-neck.

There were also eight other candidates, to each gathered a smaller fraction of the vote.

A user’s vote was recorded by a hole being punched out along the centreline of the ballot.

It appears that, due to bad user interface design,

people who intended to vote for one of the candidates, Al Gore,

instead, accidentally pressed the hole corresponding to a different candidate, Pat Buchanan.

While we’ll never know for sure, the data suggested that this is probably the case.

So, the people who vvoted in Palm Beach County using this ballot style,

about 0.85% of the votes were for Pat Buchanan.

However, people who voted absentee, using a different style of ballot,

had a much lower rate of votes for Pat Buchanan,

and the reason appears to be that this hole in the middle right here was ambiguous —

Yes, there’s an arrow pointing to it from the right, but it kind of lines up to the spot on the left.

So, it appears that for about 0.6% of voters,

they thought that that second hole corresponded to Al Gore rather than Pat Buchanan.

And the question for you is: Is this a slip? or is this a mistake?

These erroneous votes are the result of a mistake,

because voters performed the manual operation that they intended to perform —

punching that second hole —

however, they had the wrong mental model about what punching that second hole meant.

WIth better user interface design, it could have been clear

which of these was the hole that corresponded to a Democratic candidate versus the Reform candidate.

Another important lesson to learn from the butterfly ballot problem is that of consistency:

Whenever we reuse designs that are already successful, we are less likely to make accidental mistakes.

By contrast, as happens with a lot of voting systems,

when every county makes their own voting system

— or at least there’s broad diversity in the voting systems used —

it’s much more likely that usability bugs will crop up.

And so one way that we could fix this would be to have a nationwide standard voting system

where everybody votes using the same user interface.

One appealing option for a nationwide voting system would be to use electronic voting.

If we were to build a better user interface for voting, what would it be?

Well, given that we’re in a computer science class,

one natural suggestion to offer up would be electronic voting.

And electronic voting certainly has some very clear appeals:

For example, it is much easier to internationalize to many different languages;

You can have pictures of candidates to make things clear;

You can have a touch screen so that you have direct manipulation.

All of these are important and good advantages to electronic voting.

However, as David Dill in the Verified Voting Foundation point[s] out,

there’s one major problem with electronic voting:

How do you know that the machine recorded the vote that you intended?

And their proposed solution to this user interface problem is really clever:

What they proposed is that the machine print out a paper receipt of the vote that you cast;

however, you don’t get to take the receipt with you, because that would run the risk of vote-buying.

Instead, that receipt falls behind a glass or plastic clear pane,

and so you can see it being printed out, and you can see it go into a bin,

and it’s stored there for the purposes of recount.

That way, you can always manually verify the computer-generated tally.

The butterfly ballot costs problems because the representation was really confusing —

What lined up with what was hard to figure out.

Here’s an example that’s much better:

This is a seat user interface for an automobile that employs a “world in miniature” strategy.

It offers controls for manipulating parts of the seat,

and the interface for doing that is a miniature seat itself.

So, if you’d like to move the headrest back, you can move the miniature headrest back.

By having this clear mapping, users are much less likely to make errors.

So far, we’ve seen how direct manipulation enables users to behave with much more expertise

by leveraging familiar real-world metaphors.

This “directness in real-world” metaphor — like “to move a slider you move a slider” —

helps give users a good idea of how each object works and how to control it.

And also, the interface’s physical form discloses what functionality it provides.

So this is all great, right? Well, here’s the challenge:

The reason that we have technology and software as opposed to the real world that we used to have

is that we want to be able to do something new!

So, the reason that have a digital slider as opposed to a physical slider

is that, at least somewhere in the system, there’s some kind of new functionality being offered.

And so, as Jonathan Grudin points out,

if technology is providing an advantage — if there is this new functionality —

at some point, the correspondance to the real world has to break down.

So this gap between the new technology and the current practice is necessarily going to be there.

But your goal, as a designer, is to minimize this distance as much as possible.

One of my favourite examples of a user interface

that has this property of offering new functionality but minimizing the distance to current practice

is the system for DJ’s called “Final Scratch.”

This is a photograph that [inaudible] Hartman took,

and what you see here is that the DJ is operating two turntables,

much as one would do with normal vinyl.

The difference is that this is special vinyl: It has a code on the record,

and that code is being used to control a Linux system that you see on the laptop off on the left.

And so, as opposed to the record playing music that’s piped out to the speakers,

the record plays a code to the computer, and the computer plays the music to the speakers.

So why is this a good idea? Well, there’s a couple of reasons:

One, it means you can play anything, not just something that’s been produced into vinyl.

Another one is that you only have to carry two record[s], not 200.

And, more generally, it gives you all of the benefits of digital music

like, you can produce it in the morning and play it that evening —

you don’t have to wait several months for production to happen.

When used well, physical interfaces

that leverage people’s dexterity, manual abilities, and intuitions about the physical world

can be incredibly powerful.

These physical interfaces can also yield an experience that’s more fun to watch,

which, if you’re a DJ, is really important.

And, finally, here’s some resources

if you’d like to learn about mental models, errors, and butterfly ballots.