-
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.
