So far we’ve talked a lot about strategies and techniques for designing user interfaces

and we’ve talked a little bit about high-level principles.

What I’d like to do now is to kind of dive deep

and get down to brass tacks and talk about a number of concrete examples.

And so these lectures are going to offer two benefits simultaneously:

First, what I’d like to do in these next couple of lectures

is introduce a set of design heuristics for identifying interface errors and strategies for correcting them.

Second, I’d like to walk you through a number of examples of actual user interfaces,

and talk about particular ways in which they’re successful or have problems.

Now, these are all screen shots that I’ve gathered over several years.

I keep a big file of interfaces that I think are effective or have problems,

and it’s a good activity — I encourage you to do the same thing.

For any voyeurs out there, you’ll get a sense of interfaces

that I’ve stumbled across over the last several years —

not a very exciting list, but, hey.

And all of these interfaces are things that may come up again

when we talk about visual design and other principles.

So some of these screen shots you’ll see multiple times in this class.

Finally, I’d like to emphasize that we really want to focus on narrow issues in these user interfaces.

And I’m not going to talk about whether the broader ecosystem

that the particular thing we’re looking at is effective or not.

So, we may point out flaws in interfaces that are on the whole exemplary,

or we may point out successes in interfaces that are on the whole not quite so good.

And finally, because I’ve gathered these screen shots over a number of years,

many of these interfaces no longer look like this.

The point is not the current state of an interface, but rather the didactical of teaching you a principle.

Here are the ten design heuristics that we’re going to talk about.

Some of these names are mine.

The principles are based on Jakob Nielsen’s work in heuristic evaluation;

I’ve simply relabeled a few of them to make them, I think, clearer and shorter.

And so let’s jump in.

The first of these principles is “show system status.”

I think one of the most important things you can do in user interface design

is provide excellent feedback about where the system is and where the user is in a larger interaction flow.

One important thing to provide feedback about is where the user is in time.

If you have an interactive system where the response time is less than a second or so,

there is no need to have intermediate feedback: It just feels interactive.

As you get to something that’s on the order of a second or a couple of seconds,

it becomes important to provide some kind of feedback that an activity is underway.

You can think of this as hourglass or a spinning ball,

and if you get to something that’s more than a couple of seconds,

it’s useful to show progress of how far along in an activity that user is.

Here we see an example from an installation of a piece of software.

And you can see the same thing if you ask a user to fill out a survey or when they’re completing their taxes,

or any other process that takes a long time or may require multiple steps of input.

You’ll want to give people feedback about how far through the system is and how far through they are.

Second important category of things to provide feedback about and to show to the user is space.

Here’s a screen shot from Gmail which notifies me that I was out of the space allocated to me

and that means that I need to do something about it.

The third important thing to show people feedback about is change.

Here we have a dialog box that says, “You’ve changed this document.

Do you want to save those changes or don’t save them.”

Our fourth category is action. Here’s a stoplight.

So the red light means stop; the green light means go.

And I like this user interface, because it uses a redundant coding to provide feedback to the user.

So the red light is not only using red as a color, but it’s up at the top of the screen;

and the green light is also always at the bottom.

And this consistency in the dual coding both makes it faster to recognize

and it helps work for a broader class of users —

for example, not all users may be able to distinguish red from green.

Especially in an online world, it can be important to show feedback about next steps.

Here’s a screen shot from Amazon that says “Your message was sent to the seller

and a copy was sent to the email address of your account.

The seller will respond to you directly via email.”

So we’re letting the user know what’s going to happen next.

That’s important because otherwise you can wonder, “Was the message actually sent?”

or, “Did anybody get it?”

or “When they receive it, what are they going to do?”

This lays out very clearly what has happened and what will happen next.

And after you’ve crossed time, space, change, actions, and next steps,

the last thing that you’ll want to show is completion.

I also like this dialog box because it’s funny.

And a little bit of humor can be really effective in user interfaces.

Our second heuristic is to use familiar metaphors and language.

And often this can mean trying to provide a match in the interface

with things that people are familiar with from their real-world experience.

This also means speak the user’s language,

and follow conventions that they’re familiar with both in the online world and in the real world.

One important kind of familiarity is metaphors.

In this interface, I want to call your attention to the world in miniature that’s being used in the print dialog box,

and that’s an effective user interface, because it makes very clear

which pieces of the page are going to to be cropped, and which pieces of the page are going to to be printed.

In general, one of the successes of the graphical user interface

is that it leverages a lot of real-world metaphors, like desktop and trash and files and folders.

And if these are activities that users are familiar with, it can help bring them into a new online world.

Now over the last 25 years, as more and more people have gotten accustomed to computing,

some of those real-world metaphors have fallen away and newer ones have developed.

Remember that the reader of your interface is going to be a user and not your colleague, boss, or lawyer.

And consequently, work hard to identify terms and language that will be familiar to them.

Here’s a screenshot from a student loan website.

And it uses two terms that at least I was unfamiliar with —

It talked about me being I already enrolled in “Electronic Correspondence.”

And it said that I was not eligible for “Electronic Bill Presentment.”

What it really means by this, I think, is just “email,” and so it should say that.

And I don’t think of myself as being “enrolled” in an “email correspondence service.”

It would be nicer if it just said “We’re sending you email.”

And there’s some fine print about why I’m not eligible for “Electronic Bill Presentment.”

It would be much clearer if, for starters, it actually identified the reason:

in my particular case this has passed a log-in wall, and so it knows the reason.

And it would be nicer if it was able to use more common terms,

like “We’re unable to send you bills and email because,” maybe, “we don’t have an address on file.”

And it’s important to use familiar categories.

Here’s an example from a Visa website that asks users to select a state.

And, I got a kick out of it because there are more than 50 states here —

in fact, there’s a separate listing for Northern California and Southern California.

And many people in San Francisco might wish

that Northern California and Southern California were different states;

and for many people, which of those they live in or believe they live in is clear.

But for some users, this may be ambiguous, and it would probably be simpler if you just selected California

and then the system decided whether it use its Southern California routing

or Northern California routing, based on the address that you provide later.

And it’s important that the choices that you offer to people are things that they’re likely to be familiar with.

Here is a dialog box that says that “You have a document encoding mismatch.

You’ve got a document which describes itself as being UTF-8, no BOM.

But, the encoding has been set to Western, ISO Latin-1.

Now this is a developer tool,

and so it’s reasonable to expect some fluency with things that are under the hood —

like, users may in general be familiar with the idea that there are different character sets for documents —

but users may be not familiar with what exactly the difference is between UTF-8 no BOM and ISO Latin-1,

or which of them they should select, or how exactly they should go about fixing this problem.

One way that this interface could be improved is beaconing what the most common solution is likely to be.

Our third heuristic is user control and freedom, and this is going to encompass a number of things —

like exits for mistaken choices, the ability to undo and redo, not forcing people down fixed paths.

I think of this heuristic as being about making sure

that the amount of control and freedom is appropriate for the users and appropriate for the tasks.

So for example, if you have an interface that somebody’s only going to use once,

a relatively constrained wizard may actually be a good solution.

However, you may also want a way for users

to break out of that constrained wizard if they know what they’re doing and are more expert,

or have an uncommon or unique activity that they need to accomplish.

Here’s an example from a conference registration site,

and what you can see is that there’s a Continue button, but no Back button.

Here’s an interface that provides more control and freedom in the context of browsing for airline tickets.

What you see here is that there are a number of different ways

in which the user can browse through the space of possible information.

In particular you can see this calendar widget in the top left

which shows you the fares for every day of that month.

And this ability to preview what’s likely to be down a particular path is really valuable

in helping people make decisions and know what options are available to them.

Our fourth heuristic is consistency and standards.

And this includes things like consistent layout.

Here’s a screenshot of a very old set of dialog box options from Microsoft’s Visual Basic.

This is many years old at this point.

It’s pedagogically useful, because there are four different options for where the same set of buttons could be.

And probably, applications will be easiest to learn

if users can come to expect that the same buttons will always be in the same locations.

We talked already about familiar language.

It’s also important to be consistent in your use of language.

And one thing that I’ve seen on the forums is, in teaching this class,

whenever we’ve used terms interchangeably, that’s often been a source of confusion.

And you can see that in this web site.

I arrived at this screen because I wanted to get help with a USB cellular modem that I had,

and I couldn’t figure out which of these categories was most likely to be the right one.

My guess is that these categories were generated based on organizational chart for the business

rather than based on the user’s conceptual model of what they cared about.

So, for example, national access and broadband access

may be different parts of a business and have different management structures;

but from a user’s perspective, they may not know

whether the mobile device they have is in one category or the other.

So how do you solve this naming problem?

Because I think that, once you get familiar with your own products and designs,

it’s easy to refer to them using the terms that you’re familiar with.

And, to some extent, eventually training people up on these terms will be useful for everyone.

However, you’ll often want to elicit what terminology users use naturally

and ensure sure that you use that consistency.

This is actually a case where field work, or focus groups,

or other kinds of direct user engagement can be really valuable,

and you can ask people how they would describe certain things that they might want to get help with.

Another thing that you can do is if you prefer a more web-based strategy,

you can have a category initially that you call Other, and let people type in whatever they want.

And then you can look at the set of responses that come in for Other,

and use that to generate umbrellas terms that may be more user centered in terms of the language they use.

Here is a screenshot of a license repair utility, and it has a warning about the fact

that you’ll need to close all other Adobe applications before proceeding with the license repair utility.

It’s a reasonable constraint, and it says, “Do you wish to…” blank — I have blocked it out.

“Yes” or “No?”

My guess is that a good fraction of you — maybe even most of you —

would guess that [for] “Do you wish to…” the next thing would be “continue.”

And so you might press Yes.

However, what we actually have here is “Do you wish to cancel.”

And so, if you pressed Yes to continue.

It’s going to drop you out of the application and you’ll wonder what happened.

Or if you pressed No, with the intent to cancel,

you’ll actually continue, and you may run into problems.

In this particular case, one way that you can solve this problem about what Yes or No or OK or Cancel mean

is to replace Yes, No, OK and Cancel with more specific options.

So here we see a dialog box where the options are very clear:

One button says “Keep .do” as the extension name; the other one says “Use .pdf”.

And this is much clearer then OK and Cancel, or Yes and No.

Our fifth heuristic is about preventing errors, and there are lots of errors that are easy to make,

and there are lots of ways that your interface can help people prevent them.

The first kind of error to prevent people from making is data loss.

Here we have a dialog box that says “This file already exists,”

and it follows our message of having concrete button names — That’s good.

However, I don’t know what that file looks like.

If it offered me a preview, it’s much less likely that I would mistake what that file is.

In addition to preventing data loss, you can also prevent cluttering duplicates.

Here’s a screenshot that helpfully notifies you that

this may be a duplicate paper that you’re trying to import into a library.

So it says, “Hey, you’ve already got this on your computer.”

And so far as it goes, that’s great; but what I want to know is:

Is what it thinks is a duplicate actually a duplicate?

And so one button that ought to be available here and that isn’t, and that would help me prevent errors,

is by having of way of previewing what it believes the duplicate file to be,

and allows me to compare the two files, side by side.

Here’s a dialog box that says “You have unsaved data.

Click OK to go back and save, or click Cancel to continue.”

There’s a couple of problems here: For starters, we’ve got the “click Cancel to continue,”

which I think may confuse many people, and they’ll consequently lose their unsaved data.

Also, why isn’t Save one of the options on the dialog box? That would make a lot more sense.

There are many ways we could redesign this dialog box.

You could think about automatically saving things, or many other more drastic solutions.

A simple solution that we can make here is to relabel this first button to be — call this…

“Save,” and the other button we might call…

“Don’t Save, Just continue.”

And we will probably want the “Save” button to be the default action.

One of the great advantages of a graphical user interface

is that it can leverage its visual structure to enforce that users provide well-formed input

and to remind them about what parameters are necessary.

So this, for example, is the Find dialog box in Apple’s Keynote,

and you can contrast that with the Find command in the terminal.

In the graphical case, anything you can type into the dialog box will be a reasonable query to search for;

it’s impossible to have incorrect syntax.

However, in the terminal case, you have to remember every time what exactly the syntax is.

Now the terminal has lots of power and is great in lots of ways.

But the ability to make errors in terms of your syntax is one of its drawbacks.

But that doesn’t mean that just because you have a graphical interface,

it automatically will have this property of preventing errors.

This is an example of a scheduling system, and the task that we’re midstream on

is trying to schedule a weekly meeting into a conference room.

And there are some things that you need to fill out that it has explicit dropdowns for, like time and room.

However, the day field is required; it won’t let you schedule for every day..

But it doesn’t provide much in the way of widgets to do that;

and so if the user is in a hurry, they might forget to enter a day

and it’ll give an error like this that says “No day is specified.”

And what’s shocking is when you get to this point, it doesn’t give you a chance to specify the day.

So, there are several ways that we might simply revise this interface.

One is that we might make the day selection widget clearer and more salient.

And the other thing is, if somehow somebody forgets to specify a day,

the next thing that we show them would be an option to select which of the days that we want,

as opposed to just saying, “No, I’m sorry you did it wrong.”

And it’s not clear at this point how you would go back or start over to modify.

Here’s an example of a search system that provides unnecessary constraints.

I was searching for my colleague Dan Olson’s book, so I typed Olson into the search field, and Enter.

And I was hoping that it would give me a list of books, and I could select from among them.

However, it says, “No, I’m sorry, you must select a catalog to begin your search in.”

There are a number of implementation reasons why it might be preferable to select a catalog.

And in fact, once we get going, I may even want to narrow by catalog to improve the quality of my options.

But it doesn’t seem like you should need to select a catalog to get started —

at least give me some results based on any input.

That’s one thing that I think search systems, when implemented well, do a fantastic job of.

We’ll continue our tour of the heuristics in the next video.