Published: May 2014
Gerry Gaffney:
This is Gerry Gaffney with the User Experience podcast
My guest today has worked and lectured and taught at HCI since 1978, and researched indeed with companies including Cromemco, Xerox, US West, Hewlett-Packard Labs and Sun Microsystems. He has two consulting firms; UI Wizards and Wiser Usability. He has taught at Stanford University, Mills College and the University of Canterbury in Christchurch, New Zealand.
He’s co-author of “Conceptual Models” and author of “GUI Bloopers” and Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Guidelines.
Jeff Johnson, welcome to the User Experience podcast.
Jeff Johnson:
Thank you very much.
Gerry:
Jeff, the second edition of “Designing with the Mind in Mind” has just been released. I take it that means the first edition was successful?
Jeff:
Yes, well success is relative of course. I mean I’m successful as computer books go. Compared to Harry Potter, it’s, you know, miniscule.
Gerry:
The book is subtitled “A Simple Guide to Understanding User Interface Design Guidelines”. What do you think people need to understand about them? Aren’t they generally self-evident?
Jeff:
Well, the short answer is “No”. They’re not self-evident because… if you look at the guidelines that Ben Shneiderman has published or that Jakob Nielsen has published, you get guidelines like “Minimise short term memory load” and your average C++ programmer might not know what that means or why minimising short term memory load is important.
Here’s another example of a guideline: “Design task flows to yield closure”. Well, again, why do you need to do that and what does that even mean?
And so the purpose of my book was to try to give some people background in what that means, what these guidelines actually mean and why they’re important and how, in fact, you would follow them.
Gerry:
Do you think that programmers are a key audience for your book? You mentioned C ++ programmers there.
Jeff:
Well, it’s amazing how many software developers out there are given the task of designing user interfaces without having a skilled or experienced user interface designer on staff. And so they are part of the audience of the book. Also of course user interface designers, people who are trained in that are part of the audience of the book. In fact they’re probably the main audience for the book.
So, I’m really aiming at a broad audience which even includes, for example, computer users; that is people who use computers and want to understand why they sometimes have trouble.
Gerry:
Indeed, and I did find the book very accessible. It’s very readable even though you are drawing on research and relatively technical areas and even though the book is very well based on that research it is the sort of thing that, you know, any sort of reasonably literate person would be able to pick up and read.
I did very much like the structure of the book. Essentially there are fourteen chapters and each has a title describing an aspect of human perception or cognition and then the chapter discusses those aspects and contains also a discussion of the implications.
How did you arrive at that structure? Did it emerge naturally or did you have to struggle with it?
Jeff:
Well, actually what happened was that I was teaching computer science, human computer interaction at the University of Canterbury and I realised that my students were computer science students who hadn’t, mostly hadn’t taken any cognitive or perceptual psychology and so I wanted to break up the whole topic into small, digestible sort of lecture segment size pieces for them. And so that’s how I came up with that structure.
Then when I went to write the book it just seemed like a natural way to make the book easily digestible. That was actually one of my goals was to make the book something that you could pick up and put down; you know, read it for 15 minutes then put it down easily.
Gerry:
Yeah, and I did find that when I was reading it. And of course we don’t have the time to discuss each chapter in any detail but let’s pick a couple to pull out.
Can I suggest one chapter called “Human Decision Making is Rarely Rational” and in that you reflect on the old and new brain or System 1 and System 2 thinking reflecting back on Daniel Kahneman’s and some other work.
Can you tell us a little bit about that chapter and what’s in it?
Jeff:
Sure. Danny Kahneman was a psychologist who became a behavioural economist with Amos Tversky. With Amos Tversky he won a Nobel Prize in economics. This was kind of unusual for a pair of psychologists and that’s because they decided to study how people actually make decisions as opposed to how economists predicted that people would make economic and financial decisions.
So classical economists believe, or at least start with the assumption that people are rational, selfish and stable and that all decision making is rational, selfish and stable. Well, it turns out no, that’s not true. And so Kahneman and Tversky won the Nobel for essentially showing experimentally that people don’t make decisions in the way that the classical economists would predict. That was what they did back then.
At the time they didn’t really know why that was and it took modern brain science to make it clear why that is, and so Kahneman wrote a book more recently called “Thinking Fast and Slow” which breaks down our cognitive system into these two subsystems, System 1 and System 2, and there are other cognitive scientists who do the same thing. David Eagleman is another psychologist who makes this distinction and his book, I think his most recent popular book is called Incognito.
And so if you like I can talk a little bit about the differences between System 1 and System 2 and how they influence our cognition.
Gerry:
That would be great. That’ll save listeners buying the Kahneman book as well [laughs], which incidentally is excellent; “Thinking Fast and Slow”. So if you could that that would be great.
Jeff:
Well sure. So, really what modern cognitive theory says is that you can model the brain accurately by breaking it into two, or by seeing it, by perceiving it as two separate cognitive systems, System 1 and System 2. They just happen to call them that. You could also call it, System 1 could also be called the automatic system and System 2 could be called the rational, conscious system. But the overall characteristics are that System 1 is, it’s an automatic, unconscious collection of zombie processes; that’s what Eagleman calls them, “zombie processes,” that just sort of run in response to a specific stimulus or set of stimuli and they don’t require our conscious awareness and they also can run in parallel. You can actually do, for example you can be beating an egg while you watch your child play outside while you hum your favourite song. Those are all automatic processes because they’re well learned. They’re all running in System 1.
System 2 is the slow, precise calculating rational conscious system and there’s only one of it. It can’t run parallel. It can’t do multi-processing. It’s very memory intensive. When System 2 runs it’s using up short term memory at a prodigious rate whereas System 1 does not do that. System 1 doesn’t really make use of short term memory and so you can still be doing other things while you’re running all these automatic processes. But with System 2 you can only do one of those things at a time. But the interesting thing about System 2, the conscious aware one, is that because it’s the only one with consciousness, it thinks it runs the show. It thinks that it is in charge of your behaviour. In fact it is almost never in charge of your behaviour. It’s just a little bubble floating on the huge, vast mind that is System 1.
Gerry:
It’s a bit of a scary vision, isn’t it, of what we are and how we think?
Jeff:
Right, yes it is a little bit scary but Kahneman’s and Eagleman’s books and, to a certain extent, mine give example after example after example that show the distinction between those two systems.
Gerry:
You suggest a few ways that designers can exploit the characteristics of System 1 and System 2.
Jeff:
If you want your decision making to be rational you have to find ways to suppress the answers that you’re going to get from System 1. So, for example, one common example of System 1 versus System 2 is this puzzle which I’ll read. It comes from Kahneman:
“A baseball and a bat together cost $110. The bat costs $100 more than the ball. How much does the ball cost?”
Well, what happens is that almost everyone’s System 1 gives, System 1 is fast in its unconscious and its approximating. So what happens is System 1 gives you your answer right away of $10. But that’s not the correct answer. System 2… the question is how are you going to come up with the correct answer and the only way you can do that is by rejecting the answer. Basically, System 2 has to wake up, realise that the answer that System 1 has given is wrong, reject the answer, perhaps not let it come out of your mouth, and then calculate the correct answer. System 2 can calculate the correct answer and System 1 can’t calculate the correct answer. System 1 can’t do calculation. It only approximates.
So that’s an example of the difference and according to Kahneman and Eagleman people vary in how lazy their System 2 is. So, some people, System 1 runs the show most of the time and System 2 rarely wakes up and kind of intervenes. In other people, System 2 is running a lot of the time and System 1 often gets overridden but the problem with that is that System 2 – which is the conscious and rational one – is very consumptive of resources. It consumes a lot of resources; both energy, your brain by the way is a very heavily, it’s the organ that uses the most energy in your entire body, and System 2 is the heaviest user of energy. And so firing up System 2 to solve a problem in a rational way is actually very wasteful if you don’t need to.
So, most people actually try to solve problems in an automatic way. That actually leads to another interesting comment in the book which is that some users say things like “I’m in a hurry so I’ll do it the long way.”
Gerry:
Yeah, I was fascinated by that quote, which pops up a couple of times. Tell us about that.
Jeff:
Right, well what that means is that basically they have an automatic response to solving a problem and they’d rather use that than fire up System 2, which takes energy and effort and short term memory resources to figure out what the right way might be.
In other words, what a person is saying when they say I’m in a hurry so I’ll do it the long way is “I know there might be a better way to do this problem, a more rational way but I don’t have time or I don’t have energy or I don’t have the will power to actually fire up System 2 and figure it out. I’m just going to let System 1 give me the answer.” And System 1 is going to give you the answer that your brain has learned over a long period of time.
So, for example, if you know how to get to work by a very familiar route you’re going to try to use that route so that you can actually listen to the radio and think about your next vacation and do all the things in parallel. Whereas if for some reason you have to take an unfamiliar route to work then you can’t, you’re using System 2 to do that and therefore you can’t do all these other things in parallel. You have to pay attention. Attention, that’s the important word there. Your attention span is being used up.
Gerry:
So, to come back to the baseball question then. How would a designer frame that question in such a way that System 2 would be more likely to kick in and therefore come up with the correct $5 answer instead of the System 1 $10 answer.
Jeff:
You could show a bar that shows the relative costs of the two. You could use some sort of graphical method. So that gets us back to your earlier question of, you know, how can we design systems to support System 2 in overriding System 1 when we want precision and also when we’re willing to tolerate slowness of response?
So, that’s why we build what are called decision support systems. There’s a whole class of applications in our field called decision support systems and those are designed to basically provide System 2 with all the data it needs in a way that it can digest it to make decisions that are actually closer to rational than System 1 would produce.
Gerry:
You talk in the book too about the use of infographics, I don’t know if you use the term infographics, I can’t recall. But you know graphical presentation of information as being a way to I think seduce System 1 or, you know, to induce the System 2 thinking. Is that right?
Jeff:
Well, yeah, I think the term you were looking for is data visualisation or information visualisation.
Gerry:
Yeah.
Jeff:
Basically what we can do as designers is we can show information, data in a way that System 1, the automatic approximating system that is based in large part on perception, we can show the data in a way which makes it automatic. So, for example, a map might be a good example. If you give me directions from my house to your house, you can give them to me in terms of text and I can attempt to follow those but if you show me a map my eyes can see instantly and my System 1 can see instantly that you live north of where I live and therefore I wouldn’t drive south.
There might be details that I would have to scrutinise in the map, and read, in order to actually arrive at your house. What’s happening in there is that the designer is co-opting System 1 to provide the data analysis that System 2 needs to make the right decisions.
Gerry:
Yeah, it’s interesting when you were talking about maps there I was just thinking there’s at least one member of my household whom if I gave a map would be probably be more likely to be misdirected than using text instructions.
Jeff:
Really? Okay, well there are, I know that studies of cognitive differences, there are sort of map people and directions people. One of the problems with maps is, one of the disadvantages of maps is that they actually can show you all your possibilities and maybe the instructions only say, they give you essentially a tunnel, tunnel route. And so it might be possible, for example, to design a map so that the information that you don’t need that’s in the map is not so distracting. That’s actually one problem with maps is that information that you don’t need for this particular trip is there just as well as information that you do need for the trip.
o, you know, one thing designers could consider here is highlighting the route. Well and in fact that’s what many GPS systems do is they highlight your route so that you can pay attention to the parts of the map that are relevant to your trip.
Gerry:
And then of course you get into discussions of geo-centric versus ego-centric maps and whether people can transform one or the other. I mean that’s probably something we don’t want to get side-tracked with but certainly it’s an interesting area.
Jeff:
Yeah.
Gerry:
Another chapter is entitled “Our Intention is Limited. Our Memory is Imperfect,” and these characteristics have a fairly profound effect on how we need to design things.
Jeff:
Yes, people have very limited short term memory span. It’s much more limited than even cognitive psychologists thought it was. When I was in college I was told that human short term memory has, capacity is 7 plus or minus 2 items. Everyone, almost everyone who grew up in the sixties and seventies and maybe even eighties quoted that number 7 plus or minus 2 is the capacity of the human short term memory.
It’s not true.
Gerry:
Miller’s magic number as I think Miller referred to it.
Jeff:
Yeah. Correct, yeah, Miller’s experiments have been shown to have some flaws in their design that allowed some of his participants to group some of the stimuli that were presented them into what are called “chunks” and that allowed them to remember more items than the actual capacity of their short term memory.
So human short term memory nowadays is regarded as being on the average four plus or minus one. So it’s lower than… and I should say that varies. You know, some people have short term memory spans that are larger and some people have short term memory spans that are smaller. But you know on the average human short term memory is four plus or minus one, not seven plus or minus two.
So basically what we should do when we design systems in order to support the low capacity of human short term memory is to constantly remind users of where they are in a process, what step they are in a task, what things they have done versus not done. You know, it’s just like what people do themselves when they’re not using a computer. If you’re trying to count items on a page you put your finger on the items that you’re counting so that you realise which ones you’ve counted and which ones you haven’t counted.
People come up with all sorts of tricks like that in order to support their short term memory and computer systems need to do the same things. They have to show you, you know, you said you wanted to install seven items, seven apps? Okay we’ve installed these three and those four still haven’t been installed.
Or you say that you wanted to search for a particular book on Amazon? Well here’s the results and by the way here are the search terms that you searched for so that you can interpret those results.
Those are some of the implications for short term memory. Another implication for short term memory has to do with closure. Remember at the beginning I mentioned that design guideline of “design task flows to yield closure”. What that really refers to is when you are trying to do a task there’s all this stuff that you have to hold in your short term memory. You know, you’re trying to calculate your income taxes, let’s say, and so while you’re doing that there’s all this stuff that you’re sort of holding in your short term memory while you do the task. And when you’ve finished the task your brain doesn’t want to hold that stuff in short term memory anymore because holding stuff in short term memory is using System 2 and that’s energy consumptive and so you don’t want to do it, so you relax and let that stuff drop.
Well, the trouble, the fact that people do that, they let things drop, and that causes them to leave the last page of their résumé on the copier or leave the lights on in their car when they’ve gotten to a destination or fail to empty the clothes out of the dryer because basically they started the process, they got their goal and they then promptly forgot about it.
That’s the way that the human brain works and so if we want people to not make those kind of mistakes, leaving your car lights on, leaving the last page of their document in the copier, etcetera etcetera, then we have to design systems to support people in reaching closure and also in not interrupting them and that’s very important. If people are trying to do a task and they’re in a middle of a task flow – let’s say trying to buy an airline ticket – you don’t want to interrupt them in the middle of that and say, “We’ve discovered these hotels for you,” because you’re going to distract them and they’re going to forget where they were in the process of ordering an airline ticket and you want them to order an airline ticket, that’s how you make money.
Gerry:
One of my favourite examples of designing for task closure was in the old days when ATMs would give you your money and then, you know, release your ATM card and people would walk away from the machine without the card until they reversed the order of those things so that, you know, you had to retrieve the card before you completed the task you had in mind which was of course getting the money.
Jeff:
Right, right that’s perfect.
Gerry:
Another chapter in the book on visual perception is entitled “Our Peripheral Vision is Poor”. Tell us a bit about what that means and what might be the implications.
Jeff:
Okay, yeah. Well, that’s an interesting one because you know most people when they look around them in the world they sit and they look around them and they see the world in high resolution. But in fact only a very tiny area in the centre of your visual perception – it’s actually 1 percent of your visual field – is high res. The rest is so low res that if that were the way you saw you would be legally blind.
So, basically, think of it this way; you actually have vision in the centre 1 percent of your visual field and the rest of your visual field all you can really see is when things are moving and blurry blobs. By the way one way to visualise how big that centre of your visual field is is to hold out your hand at arm’s length and stick your thumb up and look at your thumbnail. Your thumbnail at arm’s length is the size of the spot in your visual field that’s high res and everything else is low res.
You know, people don’t really know that because when they look around them everything looks high res and the reason for that of course is that your eyes are moving all the time, constantly, in response to your goals, in response to stimuli in the environment, in response to movements, in response to things that you hear and also your brain is remembering what it saw when your eyes last visited a particular place and so you have this actually illusion that you’re seeing the world in high res, but that’s not true. And so where that impacts design is that designers and developers often wonder why users can’t see something on the screen because there it is, it’s right there on the screen, why don’t they see it?
When I conducted usability tests I’d often have to restrain developers who are sitting in the observation room because they’d want to bang on the glass window and tell the user that they should just move the mouse a little over to the right because what’s wrong with them? Why don’t they see that button that’s right there?
They don’t see it because they’re not looking at it. You only see things that you look at and you have to have a reason, your eyes have to have a reason to look at them.
So, this is one of the things that makes this really important in design is that it’s important to make sure that either you draw the eye in that direction – and one way to do that is movement, another way to do it is contrasting colours – or you have to put it, put the information that you want people to see where they are already looking.
One of the things that advertisers have tried, and we’ve all seen this, much to our chagrin, is, you know, advertisements that slide out into the middle of what you’re reading. You’re reading an article let’s say in the New York Times and suddenly you know a panel slides out with an ad on it right in front of your face and of course many of us just instantly we respond by clicking the close button. You know, some ads move, they wiggle and that’s going to draw your eye over that way because it might be a leopard. You know, your eye really has no way of knowing what that is that moved and, you know, a million years ago if you didn’t move your eyes in that direction you would become lunch.
Gerry:
You say in the book “we focus on our goals and pay little attention to our tools” and I often find that the designers want the tools to be noticed, you know, to be cool. How can you counter that desire?
Jeff:
One of the ways to do that is to have them read this book and books like it but I think that what really has to happen is that more techies basically have to be exposed to real users using their systems, using the systems that the techies have designed or even any system.
That’s usually an eye opening experience for many people because the assumption that many techies start with when they’re working, because they’ve gone through a program of computer science classes or design classes and, you know, they design things to be rational and make sense in their world, but they assume that people will eventually figure things out. That’s a phrase that I hear often; “Our users are smart. They’ll eventually figure things out.”
No, they will muddle through. That’s what people do. They muddle through. They muddle through life, they muddle through technology, they muddle through Microsoft Word, they muddle through, you know, Google Docs, they muddle through everything.
I think actually this shouldn’t be so hard because most techies actually have families and those families probably call on those techies for technical support. I know I’m the technical support for most of my family and if we techies would just spend some looking at actually how our uncles and aunts and brothers and sisters and mothers and fathers use the technology and understood that it’s not the way we do, that would be sort of very helpful to system design overall.
Gerry:
And I guess in a related area, you describe in the book a person or a family who never implements any of the upgrades or updates issued for their computer software. When everything eventually falls apart after a couple of years they just get a new computer and I must admit that strikes me as an eminently sensible approach to life, but I’m sure it’s anathema to many people who’d be listening to this and certainly to many technical people.
Is the non-upgrading user what we might consider to be a Luddite to use the term pejoratively?
Jeff:
No, I wouldn’t use the word Luddite because these people are using computers, they’re actually on Facebook, they’re online. The specific people you’re talking about, that I refer to in the book, they use Facebook, they use LinkedIn, they use email, they shop online, you know, they’re not Luddites. I know some real Luddites; they don’t go near a computer, okay? So the people I’m talking about in the book are not Luddites, they just, they’re in fact the people I’m talking about in that example are a doctor and a nurse, actually a teacher and a nurse and they’re not stupid, they’re smart and they’re very good at what they do. But they don’t do computers. They’re not interested in computers. They’re interested in what they can do with a computer, not in the computer itself and so any way in which the computer gets to be seen as an obstacle, they just ignore.
Why should I upgrade, you know, my computer’s telling me that I should upgrade Microsoft Office, let’s say. Well, I know that if I do that something’s going to go wrong, something’s going to be not correct or not exactly as it says in the instructions and I’m going to have to call, you know, my cousin who knows about computers.
Gerry:
Or at least engage System 2.
Jeff:
Yes, right or engage System 2 and so and I’d rather not do that. Or you know I want to make a Skype call and suddenly the audio’s not working. You and I can diagnose that and fix it as you just did.
Gerry:
Mind you, it took us fifteen minutes at the start of today’s session to do that.
Jeff:
Right but my Aunt Geraldine cannot diagnose that even though she can diagnose healthcare issues in her relatives. The diagnosis of technical computer problems is not in her tool box.
Gerry:
I guess and nor should it be. One thing that I liked about the book is there are lots and lots of examples so you’ve got, I think mostly bad examples, things to avoid but I was taken with a couple of examples where you showed improvement over time, presumably with, you know, iterative design work being undertaken.
Jeff:
Yeah, well I mean designers fortunately can learn. Designers are teachable, right? And so one of the examples that I used in my book was, I was talking about how many user interface designers initially think when I design a user interface I have to tell the user precisely and in a verbose way how to do the task, and it turns out people don’t read big blocks of text that appear on a computer screen. They just don’t but when they’re… the only time people read lots of text is when reading the text is the goal, like I’m trying to read a New York Times article. But when I’m trying to get somewhere and the text is only navigational or it’s instructional on how to use the software itself, no, I’m not going to read it. I don’t want to read it. I want to engage System 1 to get through this task. And so what people learn over time is minimise the amount of text. The designer, Steve Krug who wrote the book Don’t Make Me Think – which is a wonderful book by the way – he has the phrase “when you’re through with the design of your user interface, take the text and cut it in half, and then cut it in half again and then you’ll have about the right amount of text.”
Gerry:
My twelve-year-old recently was building something, I can’t remember what he was doing, but he got the instructions and he threw them away and he said, “I’m a man, I don’t read instructions.”
Jeff:
[Laughs.] Yeah, well you know, he’s a person who would prefer to muddle through and that’s what most people are. One of the examples in the book shows the Jeep website and how it evolved over many years with the instructions for finding the particular Jeep model you want. It used to be several paragraphs of very hard to read dense text and then a few years later it was two or three sentences and now it’s just one word and a text field.
Gerry:
Wouldn’t it be great if we could get to that point first?
Jeff:
Right, right, well that’s why I encourage people to follow Steve Krug’s advice which is, you know, figure out how much text you need to explain what you need to explain to the user and then cut it in half and then cut it in half again.
Gerry:
Tell me, how important is response time in a system?
Jeff:
Well, it’s very important because people are real time, that is the one way I think of it is there are many interfaces in computers and we often use the word “interface” to refer to the human computer interface but interfaces, there are many interfaces in computers. There’s an interface between your computer and the peripheral devices, there’s interfaces between your computer and the internet and there’s an interface between the computer and the user and that’s called the user interface. And the user interface, just like many other interfaces, is real time in that if I click on a button that button has to show me that I clicked on it immediately, and immediately by the way means within a tenth of a second, and if it doesn’t then I will click it again or I will assume I missed.
So when I click the button, the button will execute a function. I’m not saying that that function has to execute in a tenth of a second because that may be impossible. You may be asking the computer, by clicking the button you may be asking the computer to find you a discount flight to Abu Dhabi and so it may take it a few seconds. That’s fine, but what has to be instant is the fact that you clicked the button. You have to get feedback instantly that you clicked the button otherwise you’ll click it again.
And there are other examples of that kind of thing. If you drag a scroll bar and the scroll bar lags too far behind your mouse, then you’re not going to be able to effectively place the page of the document where you want it and there are many other things like that. And so what I tried to do in the book was lay out all the different time constants of human behaviour and cognition and perception and show how each one corresponds to design constraints in how fast certain things have to be in terms of computers.
And so one of the reasons I did this is that as the Web has become more important, people, designers and developers have said well, you know the Web can’t be as fast as operating software that’s on your computer. You know, operating an app on your computer that’s been installed on your computer is always going to be faster than using something over the internet so people are just going to have to get used to that. Well, yes, but that doesn’t mean that I can retrain my brain to accept the fact that a button is going to take four seconds to tell me that I clicked it. That’s not how human cognition and perception work. I can’t retrain that. That was trained by millions of years of evolution. It’s not going to be retrained in a few hours or even a few weeks or a few months.
So, the gist of that chapter of my book is, here are all the time constants of human perception and cognition and here are how you have to meet those time constraints in order to have software that people will perceive as responsive.
Gerry:
Tell me, Jeff, you’re going to be presenting at the UXPA conference in London in July. What will you be covering in that?
Jeff:
Exactly this topic. I will be giving a full day tutorial called “Designing With the Mind in Mind” and that will be interesting because in fact I’ve given short talks on this topic and I’ve given half day tutorials but this will be the first time that I will be giving a full day tutorial on this topic.
Gerry:
I’ll just remind you of the title of the book; it’s Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Guidelines.
Jeff Johnson thanks for joining me today on the User Experience podcast.
Jeff:
Thank you very much for having me.
Published: May 2014