Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 74
32_084113 ch26.qxp 4/3/07 6:12 PM Page 561
Chapter 26: Designing for Different Needs
561
Shortcuts and overview
One of the features missing from almost every help system is a shortcuts option. It is an item in the Help menu that, when selected, shows in digest form all the tools and keyboard commands for the program’s various features. It is a very necessary component of any online help system because it provides what perpetual intermediates need the most: access to features. They need the tools and commands more than they need detailed instructions.
The other missing ingredient from online help systems is overview. Users want to know how the Enter Macro command works, and the help system explains uselessly that it is the facility that lets you enter macros into the system. What we need to know is scope, effect, power, upside, downside, and why we might want to use this facility both in absolute terms and in comparison to similar products from other vendors.
Not for beginners
Many help systems assume that their role is to provide assistance to beginners. This is not strictly the case. While it’s important that there be a “quick start guide” for beginners, online help should be focused on people who are already successfully using the product, but who want to expand their horizons: the perpetual intermediates.
Modeless and interactive help
ToolTips are modeless online help, and they are incredibly effective. Standard help systems, on the other hand, are implemented in a separate program that covers up most of the program for which it is offering help. If you were to ask a human how to perform a task, he would use his finger to point to objects on the screen to augment his explanation. A separate help program that obscures the main program cannot do this.
Wizards
Wizards are an idiom unleashed on the world by Microsoft, and they have rapidly gained popularity among programmers and user-interface designers. A wizard attempts to guarantee success in using a feature by stepping users through a series of dialog boxes. These dialogs parallel a complex procedure that is “normally” used to manage a feature of the program. For example, a wizard helps a user create a presentation in PowerPoint.
32_084113 ch26.qxp 4/3/07 6:12 PM Page 562
562
Part III: Designing Interaction Details
Programmers like wizards because they get to treat users like peripheral devices.
Each of the wizard’s dialogs asks users a question or two, and in the end the application performs whatever task was requested. They are a fine example of interrogation tactics on the program’s part, and violate the design principle: Provide choices, don’t ask questions (see Chapter 10).
Wizards are written as step-by-step procedures, rather than as informed conversations between user and program. The user is like the conductor of a robot orchestra, swinging the baton to set the tempo but otherwise having no influence on the proceedings. In this way, wizards rapidly devolve into exercises in confirmation messaging. The user learns that he merely clicks the Next button on each screen without critically analyzing why. The worst thing about wizards is that they often still ask obscure questions. A user who doesn’t know what an IP address is in a normal dialog will be equally mystified by it in a wizard.
A better way to create a wizard is to make a simple, automatic function that asks no questions of users but that just goes off and does the job. If it creates a presentation, for example, it should create it, and then let the user have the option, later, using standard tools, to change the presentation. The interrogation tactics of the typical wizard are not friendly, reassuring, or particularly helpful. The wizard often doesn’t explain what is going on.
Wizards were purportedly designed to improve user interfaces, but they are, in many cases, having the opposite effect. They are giving programmers license to put raw implementation model interfaces on complex features with the bland assurance that: “We’ll make it easy with a wizard.” This is all too reminiscent of the standard abdication of responsibility to users: “We’ll be sure to document it in the manual.”
“Intelligent” agents
Perhaps not much needs to be said about Clippy and his cousins, since even Microsoft has turned against their creation in its marketing of Windows XP (not that it has actually removed Clippy from XP, mind you). Clippy is a remnant of research Microsoft did in the creation of BOB, an “intuitive” real-world, metaphor-laden interface remarkably similar to General Magic’s Magic Cap interface, discussed briefly in Chapter 13. BOB was populated with anthropomorphic, animated characters that conversed with users to help them accomplish things. It was one of Microsoft’s most spectacular interface failures. Clippy is a descendant of these help agents and is every bit as annoying as they were.
32_084113 ch26.qxp 4/3/07 6:12 PM Page 563
Chapter 26: Designing for Different Needs
563
A significant issue with “intelligent” animated agents is that by employing animated anthropomorphism, the software is upping the ante on user expectations of the agent’s intelligence. If it can’t deliver on these expectations, users will quickly become furious, just as they would with a sales clerk in a department store who claims to be an expert on his products, but who, after a few simple questions, proves to be clueless.
These constructs soon become cloying and distracting. Users of Microsoft Office are trying to accomplish something, not be entertained by the antics and pratfalls of the help system. Most applications demand more direct, less distracting, and more trustworthy means of getting assistance.
32_084113 ch26.qxp 4/3/07 6:12 PM Page 564
33_084113 afterword.qxp 4/3/07 6:33 PM Page 565
Afterword: On Collaboration
We think of the Goal-Directed method as consisting of four p’s: processes, patterns, principles, and practices. This book mostly concerns itself with the first three. In closing, we’d like to share a few thoughts about the practice of interaction design.
Interaction design is largely a difficult and messy affair (which is not to say that we don’t love it). Interaction designers are often asked to help imagine and define something that has never been seen before, using new technology on an ambitious timeline. They must develop a sophisticated understanding of a complex domain, balance competing priorities, and understand the limitations and opportunities associated with the technology at their disposal and the business context of the project at hand.
The vertigo caused by these struggles and challenges has motivated us to take a very methodical approach. When we work according to the processes described in Part I, we know that we will have the benefit of the appropriate information to answer the right questions at the right time, a sense of predictability and an audit trail for design decisions back through requirements, scenarios, personas, and research.
Patterns and principles are useful because they help us avoid wasted effort of continually examining first assumptions and reinventing the wheel.
But ultimately, these things are not enough. Process, patterns, and principles are necessary, but not sufficient, for a successful interaction design project. As much as these tools help, designers must still have the spark of inventiveness to imagine a new reality, and the experience and judgment to know if it’s good. There is no recipe for creative vision and good design judgment. And even when you believe you have the right concept, it takes considerable hard work, diligence, and skill to execute it well. One of the most challenging, chaotic — but ultimately rewarding — aspects of this hard work is collaboration with the rest of the product and business team.
33_084113 afterword.qxp 4/3/07 6:33 PM Page 566
566
About Face 3: The Essentials of Interaction Design
As we’ve discussed, interaction design needs input from and has implications for business decision makers, marketers, technologists, business analysts, and a potentially huge cast of product fabrication, quality assurance, support, and installation people, among others. If inter
action design is done in a vacuum, the product team will lack common direction and the expertise and intelligence of its members will not provide benefit to the design. As we described in Chapter 4, designers must develop an understanding of the goals, vision, and constraints of the different constituencies during stakeholder interviews early in the Research phase. However, it is also necessary to involve key stakeholders throughout the design process to provide visibility and opportunities for input and feedback, and to create buy-in for the design.
In particular, we’d to highlight three important groups with which interaction designers should collaborate. First, there are the business decision makers, who, as we discussed in the Introduction, are ultimately responsible for the profitability and success of the product and commonly fund the interaction design effort. It is important to work with these people closely at project inception to understand product vision and define user research focus, and then throughout the Requirements Definition and Framework Definition phases (see Chapters 6 and 7) to define and agree upon the product definition. Business decision makers are also important to involve in Design Refinement discussions, because the trade-offs between different solutions may involve making decisions about the development budget and timeline.
Second, interaction designers must collaborate quite closely with programmers and other technologists (such as mechanical and electrical engineers for physical products). Without the talents and abilities of these people, even the best design solutions are completely worthless. The purpose of this collaboration is to make sure that design and implementation are in perfect alignment: that designs accommodate technical and cost constraints, capitalize on technological opportunities, and are effectively communicated to programmers. Also, it is often the case that a technologist’s expertise can point in the direction of new possibilities that designers weren’t aware of.
Finally, interaction designers must collaborate with all the other people on the project team whose work impacts the overall user experience. Depending on the project, this may include design strategists, user and market researchers, industrial designers, visual designers, user documentation writers, packaging designers, and possibly even store and point-of-sale designers. The purpose of this collaboration is to ensure that all aspects of the user experience are in harmony with each other,
33_084113 afterword.qxp 4/3/07 6:33 PM Page 567
Afterword: On Collaboration
567
and not working at cross-purposes or using different design languages that could ultimately confuse the user or muddy the product’s message.
Involvement of these three critical groups best happens in two venues: at formal checkpoints that correspond to the end of each phase in the process, and at frequent, informal working meetings where new ideas are explored, evaluated, and elaborated on. Working meetings are particularly important for the second group, technologists, once the design has begun to gel, and are critical for the third group in the early stages of ideation as well as later in the process. We briefly discussed the relationship between visual, industrial, and interaction designers in Chapters 4–7.
We once believed that all design work should be completed before coding begins.
Experience has taught us that this is not a practical reality due to aggressive development schedules and, most importantly, the need to prove the feasibility of proposed design solutions. We do believe, though, that all aspects of a product should be designed before they are built. By this we mean that, even in a highly iterative process, informed planning of the user experience should always precede construction, but that it is also possible to effectively sequence work so that construction can begin on some aspects of the product while others are still being designed. This is unfortunately a much messier reality than the neat sequential compartmentaliza-tion of design and construction. To accommodate it, we’ve learned that it is critical for technologists, designers, and business decision makers to continually collaborate around the prioritization of both design and implementation activities.
Ultimately, the successful delivery of a product that meets people’s needs requires the careful coordination of the efforts of a large number of people. We’ve found that to be effective, interaction designers must ultimately assume considerable responsibility for orchestrating a fine balance between the numerous forces pushing and pulling on a product. We hope that the tools provided to you in this book will help you to create great digital products that truly satisfy your users and customers.
33_084113 afterword.qxp 4/3/07 6:33 PM Page 568
34_084113 appa.qxp 4/3/07 6:15 PM Page 569
A
Design Principles
Chapter 1
Interaction design is not guesswork.
Chapter 2
User interfaces should be based on user mental models rather than implementation models.
Goal-directed interactions reflect user mental models.
Users don’t understand Boolean logic.
Don’t replicate Mechanical-Age artifacts in user interfaces without Information-Age enhancements.
Significant change must be significantly better.
Chapter 3
Nobody wants to remain a beginner.
Optimize for intermediates.
Imagine users as very intelligent but very busy.
Chapter 5
Don’t make the user feel stupid.
Focus the design for each interface on a single primary persona.
34_084113 appa.qxp 4/3/07 6:15 PM Page 570
570
About Face 3: The Essentials of Interaction Design
Chapter 6
Define what the product will do before you design how the product will do it.
In early stages of design, pretend the interface is magic.
Chapter 7
Never show a design approach that you’re not happy with; stakeholders just might like it.
There is only one user experience — form and behavior must be designed in concert with each other.
Chapter 9
Decisions about technical platform are best made in concert with interaction design efforts.
Optimize sovereign applications for full-screen use.
Sovereign interfaces should feature a conservative visual style.
Sovereign applications should exploit rich input.
Maximize document views within sovereign applications.
Transient applications must be simple, clear, and to the point.
Transient applications should be limited to a single window and view.
A transient application should launch to its previous position and configuration.
Kiosks should be optimized for first-time use.
Chapter 10
No matter how cool your interface is, less of it would be better.
Well-orchestrated user interfaces are transparent.
Follow users’ mental models.
Less is more.
Enable users to direct, don’t force them to discuss.
Keep tools close at hand.
Provide modeless feedback.
Design for the probable; provide for the possible.
Contextualize information.
Provide direct manipulation and graphical input.
Reflect object and application status.
34_084113 appa.qxp 4/3/07 6:15 PM Page 571
Appendix A: Design Principles
571
Avoid unnecessary reporting.
Don’t use dialogs to report normalcy.
Avoid blank slates.
Ask for forgiveness, not permission.
Differentiate between command and configuration.
Provide choices; don’t ask questions.
Hide the ejector seat levers.
Optimize for responsiveness; accommodate latency.
Chapter 11
Eliminate excise wherever possible.
Don’t weld on training wheels.
Don’t stop the proceedings with idi
ocy.
Don’t make users ask for permission.
Allow input wherever you have output.
Inflect the interface for typical navigation.
Users make commensurate effort if the rewards justify it.
Chapter 12
The computer does the work and the person does the thinking.
Software should behave like a considerate human being.
If it’s worth the user entering, it’s worth the application remembering.
Chapter 13
Most people would rather be successful than knowledgeable.
All idioms must be learned; good idioms need to be learned only once.
Never bend your interface to fit a metaphor.
Chapter 14
A visual interface is based on visual patterns.