UI design notes
I just read User Interface Design for Mere Mortals. Here are some notes I copied from it.
Useful UI notes
The Seven Stages of Human Action
Many everyday tasks aren’t planned, but they’re opportunistic—on most days, people simply decide to use something when they think about it. No matter if you’ve used a product before or not, you may experience difficulties with that product because of simple misunderstandings and misinterpretations.
These misunderstandings or misinterpretations can occur anywhere along what Norman (2002) described as the seven stages of human action when performing a task:
- Forming the goal— For example, if you have a Web site with information that the user wants, the user will consider the goal to be to find the information on the site.
- Forming the intention— If the user believes that the Web site contains information she needs, she will make a decision to find that information.
- Specifying the action— The user needs to identify which link to click on that she believes will get her closer to reaching the information on the Web site.
- Executing the action— The user clicks the link to get to the next level in the Web site.
- Perceiving the state of the world— The new Web page appears in the user’s Internet browser, and the user reads the page and perceives what has happened as a result of executing the action.
- Interpreting the state of the world— The user processes the information on the new Web page and determines if the information on the Web site is the information she seeks.
- Evaluating the outcome— The user determines whether clicking the link met the desired outcome. If it didn’t, she must decide whether clicking another link on the new page will get her closer to the desired outcome.
People can use one, some, or all of these stages when performing a task, and there is a continuous feedback loop. Misunderstandings and misinterpretations can come from people who are not using all of the stages for some reason, such as confidence that they’ve used a similar product in the past and belief that their actions will work for a new product just as well. Other misunderstandings and interpretations can come from poor design that fails to account for how the user perceives the state of the world.
Transforming Difficult Tasks into Simple Ones
So how does a designer create something that’s as usable as possible before talking with users? Suggest to the designer that he follow Norman’s (2002) principles for transforming difficult tasks into simple ones:
- Realize that users use knowledge in their brain and in the world— People need to use both types of knowledge to get an accurate sense of what’s going on around them. When a user approaches a user interface, he brings information with him from related tasks (the brain) and gains feedback from the user interface itself (the world) to make an accurate assessment of the task at hand. As a designer, you need to observe what information the user brings to the task in the usability test and learn how he responds to the feedback from the interface.
- Simplify task structures— If you have an interface in which it takes two clicks to get to a piece of information that could be reduced to one click, reduce the work for the user.
- Make things visible— If you can make user interface options visible without adding to clutter on the screen and overwhelming the user, do so. This is a real balancing act, but you will gain the right balance after you see how users react to the interface in your usability tests, as you’ll learn about in Chapter 9, “Usability.”
- Ensure that the mappings are correct— A user’s perceptions that a product is quick to use is based more on the speed at which the user finds information than the speed at which the interface or Web site loads (Eisenberg and Eisenberg, 2006
- Exploit constraints to make a better product— User interfaces can be constrained by the operating system, such as your interface being required to reside within a window.
- Design for error— Think of all the ways users could use the program for destruction, and then plan for that. One way to do that is to write use cases, which are written forms that include every conceivable way the user could cause errors, and then plan around those. You can mitigate many of these errors before you conduct your usability test.
- When all else fails, standardize— Fortunately, in the case of user interface design, the constraints imposed by the operating system on your design also provide you with a great deal of standardization. If you have a Web site, the design rules are more fluid, but books and Web sites are available that provide examples of good and bad design practices so you can learn about standards for usable and effective Web sites.
When a person tries to perform a task for the first time, she goes step by step through creating this conceptual model by asking three questions (Norman, 2002):
|
1. |
What affordances does this product provide? Norman refers to the perceived and actual properties of something as affordances. Affordances give you clues as to perform fundamental tasks using an object. For example, as I look at a cup with a handle on it, I can see that my options are limited. I can see that the handle is there to grasp. The handle is an affordance. |
|
2. |
What constraints are there? When I put my fingers into the cup handle, I find that I can put in only so many fingers, which is aconstraint. (It could be argued that you can leave your pinky finger free to extend it in an elegant manner, which could be an affordance.) |
|
3. |
How do you map the possible operation? As I put my fingers in the cup handle, I learn that the fingers I use don’t affect the use of the cup, but the handle does suggest how the cup is to be used. |
how do you design a product that does create a good model? Norman (2002) suggests four features that designers should consider as they create a product:
- Keep things simple so that users can form a good mental model that maps the use of the object to perform a task— For example, in a user interface, you shouldn’t overwhelm the user with buttons if at all possible. This is especially true in Web design, where good designers adhere to the three-click rule. This rule states that if the user has to click more than three times to get to his desired location, he’ll lose interest and won’t revisit your site.
However, Albert Einstein once said that you should make things as simple as possible, but no simpler. It’s easy to make things so simple that users won’t be able to understand how to use it—or even find where the tool is. For example, when I visited my sister and brother-in-law and wanted to use their shower, I didn’t know how to switch the water flow from the bathtub spigot to the showerhead. There was no knob, lever, or anything. My brother-in-law finally discovered that there was a ring around the lip of the spigot that switched the water flow once you pulled the ring down. I had never seen anything like that before.
- Keep things visible— For example, if you make a phone call to someone and you don’t want to be interrupted by call waiting, you may be unpleasantly surprised if you don’t see anything on your phone that informs you that call waiting is on and you don’t remember to turn it off.
- Provide good mapping between the object to be manipulated to perform a task and the results of that manipulation—However, you can easily overlook this mapping process because you’re so intent on keeping the experience consistent. That’s true with Apple’s iPod. Despite the iPod’s popularity, users have fielded interface complaints about it. One problem is that if you want to change the volume if you’re in another part of the interface (like the calendar), there isn’t a way to quickly go back to the main menu and access the volume controls. You have to go back through one or several menu screens to get back to the main menu so that you can change the volume.
- Provide good feedback continuously about the results of actions that the user takes— This can be as simple as showing if the unit is on or off, as in the case of the Palm Treo. Clicking most of the buttons on the front of the unit won’t turn the unit on, so the user can determine how to turn the unit on by trial and error. Programs also emit an audio or visual warning if you click a button or perform an action that you can’t do.
If you plotted user experience levels on a graph, you would find that they adhere to a bell curve. Most of the users on this bell curve have an intermediate level of knowledge, and you can design your user interface to meet the needs of this large group of users.
Because people form mental models that are simpler than reality, designers should always strive for simplicity—one of Norman’s (2002) principles for transforming difficult tasks into simpler ones. (You may have heard of the acronym KISS, which means Keep It Simple, Stupid.) Users don’t care about how something works, and they don’t care if their perceptions are accurate or even true. They understand what they interact with, and they expect the interface to reflect their own model as much as possible. The closer that the implementation model is to the mental model, the easier the interface for the user.
Cooper and Reimann (2003) identified the problem as being a disconnection between research performed by market analysts and the design of the interface performed by designers. To fill in the gaps, Cooper and Reimann created the Goal-Directed Design Process for software engineering and user interface design. These gaps are in the forms of three new primary activities between the research and refinement stages.
The entire five-step Goal-Directed Design Process combines ethnography (a method of studying and learning about a person or group of people), research, modeling, and design into five phases, in the following order (Cooper and Reimann, 2003):
|
1. |
Research—This phase uses observational and contextual testing as well as interviews to learn more about potential and actual users of the product. One of the primary outcomes of research is the discovery of usage patterns, which suggest the goals and motivations for using the product. For example, if you do research on word processors, one motivation is to write and edit documents more quickly than doing so by hand. You will learn more about observational and contextual testing in Chapter 9, “Usability.” |
|
2. |
Modeling—After the research is completed, the modeling phase analyzes the research for user and workflow patterns, and from that creates user models based on those patterns. Those models are based on groupings of user goals, motivations, and behavioral patterns. From these user models, or personas, the project team determines how much influence each persona will have on the interface design. You’ll learn more about personas in the next section. |
|
3. |
Requirements—In this phase, the project team creates requirements that meet the needs of one or more of the personas you identified in the modeling phase. To meet the requirements, you need to learn more about the user in the environment in which he would be using the interface. That takes user and task analysis, which you’ll learn about later in this chapter. The result of this phase is a requirements definition that balances the needs of the user, the business, and the technical necessities. |
|
4. |
Framework—Designers create an interaction framework that produces a structure for the program so they can add the remainder of the code later. This framework melds general interaction design principles with interaction design patterns to create a flow and behavior for the product. Parts of the framework include input methods, views, data elements, functional elements and groups, and group hierarchy. You’ll learn more about creating an interaction framework in Chapters 7, “Designing a User Interface,” and 8, “Designing a Web Site.” |
|
5. |
Refinement—This phase refines the framework and includes detailed documentation of the design as well as a form and behavior specification. This phase defines what the design should do to meet the goals of each persona identified in the Modeling phase as well as the business that employs the persona. For example, you should identify a problem that both the persona and business are having, such as having inadequate tools to gain customer feedback, and then identify the solution that your interface will provide to the persona and the business. |