Let’s take a look at your museum website planning pieces from last week:
- Design Brief
- Project Home Content
- Site Structure Diagram
User Experience Design
The term user experience is used in the web industry to refer to all aspects of the end-user’s interactions with a website. It includes the ease of use and degree of pleasure the user finds in the experience. The way a user interacts with a website–successfully or unsuccessfully–tends to color his or her feelings about the entire brand.
According to author Don Norman,
I invented the term because I thought human interface and usability were too narrow. I wanted to cover all aspects of the person’s experience with the system including industrial design, graphics, the interface, the physical interaction, and the manual. Since then the term has spread widely, so much so that it is starting to lose it’s meaning… user experience, human centered design, usability; all those things, even affordances. They just sort of entered the vocabulary and no longer have any special meaning. People use them often without having any idea why, what the word means, its origin, history, or what it’s about.
We did discovery last week. We need to understand everyone’s expectations.
Design includes discovery, but here we mean making decisions about the design.
When we produce, we are creating mockups and coding the site.
Finally, we need to set goals with specific things to measure. Then we check frequently to evaluate if the goals are being met. If not, we make changes and try something else.
In software, we talk about whether or not an application is “intuitive” or not.
Jef Raskin, the original Macintosh interface designer, pointed out that “intuitive” is really the wrong word. “Familiar” is more on target.
When designing software it helps to try to pinpoint where on this continuum your users will likely be.
Some software can take a lifetime to learn and be very complex, some can be simple and straight forward to use.
You can’t expect software that has a wide open canvas, and a huge number of tools/features/effects (like Photoshop), to be completely intuitive.
Nor should you expect your website users to have to learn how to use something to accomplish a task they only need to do once.
Patterns Can Help
Lucky for us, we don’t have to start from scratch. A huge amount of work has gone into finding familiar sets of controls and configurations that work. These are called patterns. Instead, our job is to find the correct pattern, or combination of patterns for our particular application.
We’ll take a look at patterns for web interfaces shortly. But first, let’s take a look at the patterns users take when interacting with websites.
User Behavior Patterns
These are what we need to keep in mind when designing web interfaces! These patterns do not describe user interface elements, but describe aspects of users we can all recognize. Can you think of some recent examples in your web experience?
“Let me explore without getting lost or getting into trouble.”
When someone feels like she can explore an interface and not suffer dire consequences, she’s likely to learn more and feel more positive about it than someone who doesn’t explore. Good software allows people to try something unfamiliar, back out, and try something else, all without stress.
“I want to accomplish something now, not later.”
People like to see immediate results from the actions they take; it’s human nature. If someone starts using an application and gets a “success experience” within the first few seconds, that’s gratifying! He’ll be more likely to keep using it, even if it gets harder later. He will feel more confident in the application, and more confident in himself, than if it had taken a while to figure things out.
“This is good enough. I don’t want to spend more time learning to do it better.”
When people look at a new interface, they don’t read every piece of it methodically and then decide, “Hmmm, I think this button has the best chance of getting me what I want.” Instead, a user will rapidly scan the interface, pick whatever he sees first that might get him what he wants, and try it even if it might be wrong.
The term “satisficing” is a combination of “satisfying” and “sufficing.” It was devised in 1957 by the social scientist Herbert Simon, who used it to describe the behavior of people in all kinds of economic and social situations. People are willing to accept “good enough” instead of “best” if learning all the alternatives might cost time or effort.
Changes in Midstream
“I changed my mind about what I was doing.”
Occasionally, people change what they’re doing in the middle of doing it. Someone may walk into a room with the intent of finding a key she had left there, but while she’s there, she finds a newspaper and starts reading it. Or she may visit Amazon to read product reviews, but ends up buying a book instead. Maybe she’s just sidetracked; maybe the change is deliberate. Either way, the user’s goal changes while she’s using the interface you designed.
“I don’t want to answer that now; just let me finish!”
This follows from people’s desire for instant gratification. If you ask a user several seemingly unnecessary questions while he’s trying to get something done, he’d often rather skip the questions and come back to them later.
For example, some web-based bulletin boards have long and complicated procedures for registering users. Screen names, email addresses, privacy preferences, avatars, self-descriptions…the list goes on and on. “But I just wanted to post one little thing,” says the user plaintively. Why not skip most of the questions, answer the bare minimum, and come back later (if ever) to fill in the rest? Otherwise he might be there for half an hour answering essay questions and finding the perfect avatar image.
“Let me change this. That doesn’t look right; let me change it again. That’s better.”
When people create things, they don’t usually do it all at once. Even an expert doesn’t start at the beginning, work through the creation process methodically, and come out with something perfect and finished at the end.
Quite the opposite. Instead, she starts with some small piece of it, works on it, steps back and looks at it, tests it (if it’s code or some other “runnable” thing), fixes what’s wrong, and starts to build other parts of it. Or maybe she starts over if she really doesn’t like it. The creative process goes in fits and starts. It moves backwards as much as forwards sometimes, and it’s often incremental, done in a series of small changes instead of a few big ones. Sometimes it’s top-down; sometimes it’s bottom-up.
Builder-style interfaces need to support that style of work.
“That gesture works everywhere else; why doesn’t it work here, too?”
When one uses an interface repeatedly, some frequently used physical actions become reflexive: typing Control-S to save a document, clicking the Back button to leave a web page, pressing Return to close a modal dialog box, using gestures to show and hide windows, or even pressing a car’s brake pedal. The user no longer needs to think consciously about these actions. They’ve become habitual.
This tendency certainly helps people become expert users of a tool (and it helps create a sense of flow, too). Habituation measurably improves efficiency, as you can imagine. But it can also lay traps for the user. If a gesture becomes a habit and the user tries to use it in a situation when it doesn’t work or, worse, does something destructive then the user is caught short. He suddenly must think about the tool again (What did I just do? How do I do what I intended?), and he might have to undo any damage done by the gesture.
“I swear that button was here a minute ago. Where did it go?”
When people manipulate objects and documents, they often find them again later by remembering where they are, not what they’re named.
Take the Windows, Mac, or Linux desktop. Many people use the desktop background as a place to put documents, frequently used applications, and other such things. It turns out that people tend to use spatial memory to find things on the desktop, and it’s very effective. People devise their own groupings, for instance, or recall that “the document was at the top right over by such-and-such.” (Naturally, there are real-world equivalents too. Many people’s desks are “organized chaos,” an apparent mess in which the office owner can find anything instantly. But heaven forbid that someone should clean it up for them.)
“I’m putting this here to remind myself to deal with it later.”
Prospective memory is a well-known phenomenon in psychology that doesn’t seem to have gained much traction yet in interface design. But I think it should.
We engage in prospective memory when we plan to do something in the future, and we arrange some way of reminding ourselves to do it. For example, if you need to bring a book to work the next day, you might put it on a table beside the front door the night before. If you need to respond to someone’s email later (just not right now!), you might leave that email on your screen as a physical reminder. Or, if you tend to miss meetings, you might arrange for Outlook or your Palm to ring an alarm tone five minutes before each meeting.
Basically, this is something almost everyone does. It’s part of how we cope with our complicated, highly scheduled, multitasked lives: we use knowledge “in the world” to aid our own imperfect memories. We need to be able to do it well.
I have to repeat this how many times?”
In many kinds of applications, users sometimes find themselves having to perform the same operation over and over again. The easier it is for them, the better. If you can help reduce that operation down to one keystroke or click per repetition or, better, just a few keystrokes or clicks for all repetitions then you will spare users much tedium.
Find and Replace dialog boxes, often found in text editors (Word, email composers, etc.), are one good adaptation to this behavior. In these dialog boxes, the user types the old phrase and the new phrase. Then it takes only one “Replace” button click per occurrence in the whole document. And that’s only if the user wanted to see or veto each replacement if they’re confident that they really should replace all occurrences, then they can click the “Replace All” button. One gesture does the whole job.
“Please don’t make me use the mouse.”
Some people have real physical trouble using a mouse. Others prefer not to keep switching between the mouse and keyboard because that takes time and effort they’d rather keep their hands on the keyboard at all times. Still others can’t see the screen, and their assistive technologies often interact with the software using just the keyboard API.
For the sakes of these users, some applications are designed to be “driven” entirely via the keyboard. They’re usually mouse-driven too, but there is no operation that must be done with only the mouse; keyboard-only users aren’t shut out of any functionality.
Other People’s Advice
“What did everyone else say about this?”
People are social. As strong as our opinions may sometimes be, what our peers think tends to influence us.
Witness the spectacular growth of online “user comments”: Amazon for books, IMDb.com for movies, photo.net and flickr for photographs, and countless retailers who offer space for user-submitted product reviews. Auction sites like eBay formalize user opinions into actual prices. Blogs offer unlimited soapbox space for people to opine about anything they want, from products to programming to politics.
Web Design Patterns: UI Patterns
“User Interface Design patterns are recurring solutions that solve common design problems. Design patterns are standard reference points for the experienced user interface designer.”
I encourage spending a lot of time at this site during this course.
User Interface Design Patterns
- Getting input: getting the user to input data, tailored to the context of use
- Navigation: helping the user locate specific features and content
- Dealing with data: allowing for the search, formatting, and browsing of data
- Social: allowing the user to associate, communicate, and interact with other people
Persuasive Design Patterns
- Cognition: psychological tendencies that cause the human brain to draw incorrect conclusions
- Perception and memory: how we visually perceive, interpret, and remember meanings as we interact with systems
- Game mechanics: games engage, involve, and influence us through its playful nature
- Feedback: as the users interact with your system feedback, motivate them to take the next step
Web Design Patterns: jQuery UI
- Effects, such as color animations and hide/show
Mental Model Defined
What users believe they know about a UI strongly impacts how they use it.
A mental model is what we believe to be true. This is generally based on our experiences. It affects how we assimilate new things into our existing knowledge.
A mental model is not necessarily the truth. In fact, individual users may come to your interface each with their own mental model. But in many cases, it’s okay if they don’t really understand how it works, if it simply works in a familiar way.
For users to feel good about your website, they need to feel as if they understand it. Making it as simple as possible for them to understand–even if that simple understanding is completely inaccurate–is what author Robert Hoekman, Jr. calls designing the obvious.
For example, we don’t need to know what changes our computer makes to the file structure when we choose to delete a file. We understand what a trash can is for, so most interfaces use the icon of a trash can for “throwing stuff away”.
Even the concept of file organization in an operating system matches closely with our mental model of a filing cabinet. Sheets of paper (files) go into folders with labels, and folders go into bigger, hanging folders that also have labels.
The mental model of using a pencil is good enough for using the pencil tool in Photoshop, though the physical realities of graphite on paper versus electronic connections in a drive are vastly different.
The implementation model is what we get when the underlying details of a system influence the design of the interface. For example, before we had icons of files and folders in an operating system, we had the command prompt. The command prompt forces us to remember obscure details about language and syntax far removed from the everyday experience of most people.
Implementation models often aim to please the geeks that create them, and they take very little thought about mental models to create them. In web applications, many implementation-model designs appear when there are far better ways to represent the functionality of the interface.
For example, error messages in interfaces sometime are cryptic, and written in words that make sense to a developer. This is great in a production environment, but by the time users interact with your design, the error messages should be crafted to help them understand what is wrong, what to do about it, and how the application actually works.
Another example is when interfaces show you every possible option and setting all at once. It’s like the programmers are showing off. But that simply overwhelms the user. Instead, users want to see only what is relevant to them while involved in a specific task at a given point in time. Hide everything else for now.
Because designers know too much, they form wonderful mental models of their own creations, leading them to believe that each feature is easy to understand. Users’ mental models of the UI are likely to be somewhat more deficient, making them more likely to make mistakes and find the design much more difficult to use.
Don’t assume that because something is possible and us geeks think it would be cool, that users will grasp it and make use of it. And don’t use labels on interface items that are meaningless to users. Use what they already know about.
- Adobe Photoshop versus Photoshop Elements
A metaphor is when a thing is representative or symbolic of something else. Many web interface elements need to use metaphors in order to match the mental model of the user.
Let’s take a look at a good use of metaphor and mental model: Google Calendar. You can log in to your own and check it out if you have a Google account.
Metaphor for: a Real Calendar
Real calendars are generally made of paper and allow you to flip pages, and write on them to keep track of appointments, significant dates, or events.
The Google Calendar interface has a lot in common with a paper-based calendar. It uses a grid to lay out the days of the week, and weeks of the month.
- Google Calendar interface
Click on an individual date, and a popup allows to to label an event or task, similar to jotting this down with a pencil.
- Google Calendar add an item
Enter your event name. You can either click Create event and be done with it, of click Edit event to do more. Now is when the interface reveals all kinds of other functions that were hidden before, when you did not need them yet.
- Google Calendar edit event
You can other reconfigure the interface considerably.
- Google Calendar agenda and settings
But what you are first presented with when you arrive is a familiar interface most of us can start using right away.
Finally, don’t forget that if a certain convention is used by the majority of website interfaces, that becomes part of a user’s mental model of how websites work. Which is not to sat you can’t deviate from that, but do be aware of that fact.
- Basic website template
Preproduction: Mood Boards
A mood board is a type of poster design that may consist of images, text, and samples of objects that express the mood of a future design piece. Designers use mood boards to develop their design concepts and to communicate to other members of the design team. Mood boards are often used by graphic and web designers to enable them to illustrate visually the direction of style which they are pursuing.
Mood boards can be arranged in a variety of ways, from loose collages to formal, organized layouts.