In my column, On Good Behavior, I’ll explore the essentials of good interaction design. This first column provides a brief introduction to interaction design—defining the scope this column will cover—then explores some key design principles. What is interaction design? Here’s the definition I wrote for the UXmatters Glossary:
“Interaction design defines workflows that support users’ goals and tasks, the affordances through which digital products and services communicate their functionality and interactivity to users, the ways in which users can interact with those affordances, products’ behaviors in response to user interactions, and the methods by which products indicate state changes. Good interaction design facilitates people’s tasks and ensures that digital products are both learnable and usable by reducing complexity as much as possible, preventing user error, adhering to standards when appropriate, and through consistency across an entire product or product line. Typical interaction design deliverables include specifications, wireframes, usage scenarios, and prototypes.”
As you can see, interaction design is a complex design discipline that must take many different factors into account to solve a wide range of design problems. So, how do interaction designers get their heads around wicked design problems?
“Design depends largely on constraints. … Here is one of the few effective keys to the design problem—the ability of the designer to recognize as many of the constraints as possible—his willingness and enthusiasm for working within these constraints….”—Charles Eames
Many different kinds of constraints bound our solutions to interaction design problems, including
users’ physical and cognitive abilities
design principles and guidelines
the amount of space available for a feature
Being able to make the necessary tradeoffs between conflicting constraints takes skill. I’ve always viewed constraints as my friends. They make me more creative. By thoroughly understanding the limitations that constrain a design solution, I can make the right tradeoffs and come up with the best design solution possible under those constraints. Plus, balancing different constraints often forces me to think outside the box, so inspires innovative design solutions.
Whether you are designing interactions for desktop, Web, or mobile applications, there are some foundational design principles you should always follow. In The Humane Interface, Jef Raskin gave us his first and second laws of interface design:
“A computer shall not harm your work, or through inaction, allow your work to come to harm. … A computer shall not waste your time or require you to do more work than is strictly necessary.”—Jeff Raskin
In this column, I’ll cover some basic design principles whose violation either interferes with users’ work, resulting in frustration for users, or actually harms their work. Unfortunately, users encounter egregious violations of these principles every day—and these are the sorts of design errors that become users’ pet peeves.
Give Users a Sense of Being in Control
Users need to feel that they are in control, so should generally initiate interactions. Almost every collection of user interface design principles includes this important tenet.
“Allow the user, not the computer, to initiate and control actions. Some applications attempt to assist the user by offering only those alternatives deemed good for the user or by protecting the user from having to make detailed decisions. Because this approach puts the computer, not the user, in control, it is best confined to parts of the user interface aimed at novice users. Provide the level of user control that is appropriate for your audience.”—Apple Human Interface Guidelines
“An important principle of user interface design is that the user should always feel in control of the software rather than feeling controlled by the software. … You can automate tasks, but implement the automation in a way that allows the user to choose or control it.”—Microsoft Windows User Experience
“Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.”—Ben Shneiderman’s “Eight Golden Rules of Interface Design,” from Designing the User Interface: Strategies for Effective Human-Computer Interaction
“Users prefer to feel a sense of mastery and control over any tool at their disposal, and the computer is no exception. The designer should be sensitive to this and present a tool-like interface.”—Deborah J. Mayhew’s “General Principles of User Interface Design,” from Principles and Guidelines in Software User Interface Design
“Allow users to be in control of the interface. Don’t limit users by artificially restricting their choices to your notion of the ‘correct’ sequence of steps needed to accomplish a task. … Allow users to establish and maintain a working context, or frame of reference, from within which they can perform actions. … This contextual framework contributes to the feeling of stability.”—IBM, “Design Principles for Tomorrow”
Now, let’s look at some examples of behaviors designers should avoid to ensure they leave control in users’ hands.
Window Behaviors Beyond Users’ Control
Many computer operations unnecessarily wrest control from users, interrupting their work and, in some cases, even preventing them from doing anything at all. For example, when a user opens an application like a Web browser that requires reopening a lot of windows from the user’s prior work session, the browser insists on bringing newly opened windows to the front. This is a huge and frequent time-waster for users. During such out-of-control interactions, a user’s attempting to do useful work results in an extremely unstable user experience, with the application repeatedly taking control from the user. Why in the world should a user have to monitor everything the browser does while it automatically opens all of those windows? A user should instead be able to work in another application, while the browser opens those windows in the background. If a user clicks a window to bring it to the front, the assumption should be it’s the window the user wants, so should remain in front. This is a problem that computer operating system design should solve.
Popup ads provide an obnoxious example of abrogating user control, forcing users to both view information they didn’t ask to see and close the windows in which the ads appear, wasting users’ time. While Netflix has a well-designed Web site, the company is one of the worst offenders when it comes to popup ads, which is damaging to the company’s credibility. Figure 1 shows a Netflix popup ad.
Unnecessarily Modal Dialog Boxes
Modal dialog boxes limit users’ possible interactions, because they require users to either complete or cancel an interaction and close a dialog box before they can do anything else. You should avoid designing modal dialog boxes unless they are absolutely necessary—that is, when an application needs more information before it can complete a user’s current task and it’s important to restrict user interactions to a certain order. Avoid modal dialog boxes for frequent interactions.
Figure 2 shows the modal Paragraph dialog box in Microsoft Word for Mac OS X. There is no reason for this dialog box to be modal. If it were modeless, a user could successively select different paragraphs and make changes to their formatting, making a repetitious task more efficient.
Generally, modal dialog boxes should be movable to ensure users can see any content that affects what they need to do within a dialog box. This is true for both dialog boxes in desktop applications and dialog boxes in Ajax Web applications. It’s extremely frustrating for users when a dialog box obscures information in the window beneath it that is essential to successfully completing a task.
Not Letting Users Cancel Time-Consuming Processes
Always allow users to cancel time-consuming processes occurring in modal dialog boxes or progress message boxes. If users don’t want to wait for a lengthy operation to complete, they need to be able to change their minds and do something else instead. In Microsoft Word for Mac OS X, if a user chooses File > Open Recent > More, it takes forever for the resulting dialog box to appear. While a spinning progress indicator churned away—giving no indication of how long Word might take to display the data—and the Project Gallery dialog box displayed no Cancel button, I counted slowly to 95 before any content appeared in the dialog box, which Figures 3 and 4 show.
If the designer had instead specified that all controls should appear in the Project Gallery dialog box before populating the dialog box with any file data, a user would be able to either click Cancel to escape the wait altogether or click one of the filters on the left, then have to wait for only a subset of the data to load.
Overlays That Interrupt Users’ Flow
The first time I encountered a user interface that presented overlaid information to users on rollover was with Mac OS System 7.0’s Balloon Help. Its balloons provided descriptions of onscreen items such as file icons, menu commands, and controls in windows and dialog boxes, as shown in Figure 5. Because this feature incorporated no delay before its balloons appeared on the screen, balloons appeared willy-nilly whenever a user moved the pointer across the screen. Users hated Balloon Help, because they found its balloons distracting.
Microsoft Windows’ implementation of ToolTips and balloon tips has been more successful, because it incorporates a 500-millisecond delay. ToolTips and balloon tips appear only after the pointer has hovered over a control for 500 milliseconds. The use of ToolTips is now prevalent in Web applications like Google Docs as well, as shown in Figure 6.
Today, users encounter the same problem we saw with Balloon Help in many Web applications. When large overlays and drop-down menus appear on rollover, they interrupt users’ flow. For example, on the new Yahoo! home page, a massive overlay appears immediately whenever a user’s pointer wanders into My Favorites, as shown in Figure 7. The appearance of these overlays is extremely disruptive to users’ completing their goals, because they are modal and getting rid of them requires users to click the close box in the upper-right corner of an overlay. The behavior of these overlays is particularly disconcerting, because a large part of Yahoo!’s motivation for displaying them seems to be the opportunity to include more display ads on the home page. They should instead appear only when a user clicks them.
Drop-down menus that appear with no delay provide another example of overlays whose appearance can interrupt users’ work, especially if there are other controls above a menu bar that a user might want to click. For example, in Movable Type, the menus on its menu bar, shown in Figure 8, appear without any delay, so sometimes appear when a user doesn’t intend them to. In this case, a drop-down menu on the UXmatters tab and the Create drop-down menu are stacked, one above the other, so if a user wants to view the UXmatters drop-down menu, it’s likely the Create drop-down menu will appear as the pointer traverses it. And when a user wants to click the frequently used Write Entry button, the Manage drop-down menu will probably appear as the pointer moves across it. Drop-down menus in Web applications should preferably appear only when a user clicks them, replicating the behavior of menus in desktop applications.
When designing interactions, be sure to keep this principle is mind: Users’ goals are paramount. An application should do nothing to impede users’ attainment of their goals. Whenever applications display overlays users don’t want to see, they interrupt the flow of the users’ work. So, if overlays of any type obscure other elements in a window, do your users a favor and display them only after a 500-millisecond delay.
Playback That Interferes with What Users Want to Do
Have you ever restarted your browser and found yourself inundated by a cascade of various waves of sound emanating from God knows where? Were you perhaps trying to talk on Skype or another VoIP (Voice over Internet Protocol) application at the time? This kind of scenario sets users scrambling, trying to figure how to turn off every audio source except the one they’re using. On ABC’s Web site, when a user navigates to the directory of all ABC shows, shown in Figure 9, a video ad immediately starts playing, which then segues to a video clip from a show. At least there’s an easy way to pause the video—that is, once the user finds the window and tab from which the audio is emanating. Not always easy to do.
Audio and video recordings should never play automatically when a Web page loads. Instead, provide a Play button that a user can click to play them. ABC gets it right on their home page, shown in Figure 10. Videos play only when a user clicks a play button.
Even worse are looping audio tracks that play automatically when users navigate to Web sites. In a particularly obnoxious example, a Flash Web site plays music continuously, as long as a user remains on the site. As shown in Figure 11, the only way to get rid of the music is to click a poorly labeled music link, which is at the very bottom of the page, below the fold! Not the best use of a link affordance either.
Carousels with Unexpected Behaviors
Many carousels provide examples of taking control away from users. Either they automatically whisk something away just as a user is about to click it or the user inadvertently changes their display. The latter occurs when a carousel’s view changes on rollover rather than click and, while a user is reading the opener for an article,the user inadvertently moves the pointer over another selector, displaying different content. At that point, the user either has to figure out how to navigate back to the content that was of interest or give up entirely.
The news carousel on the former Yahoo! home page was the variety that automatically whisked content away; that on the new Yahoo! home page, shown in Figure 12, is the type that changes when a user points to a different selector, whether the user’s movement of the pointer is intentional or not. Changing a carousel’s view on rollover rather than on a click can introduce instability.
There are many examples of automatic carousels on news, magazine, and video sites. While carousels that display a lot of text can be problematic if their behavior is not specified properly, those on video sites generally are not, as long as they don’t cycle too quickly. For example, Figure 13 shows a carousel on hulu that cycles slowly and is very navigable. In addition to using the arrows to move forward or backward, a user can click the control beneath the carousel to navigate to any view.
One problem with automatic carousels—whisking something away when a user is about to click it—can be overcome if a designer specifies that the display should not change if the pointer is within the display region like that on CNET, shown in Figure 14.
Overly Controlling Help Systems
Help systems should restrict neither users’ access to information nor what users can do at any given moment. In Mac OS System 7.5, Apple Guide spoon fed Help for a task to users one step at a time, using red coach marks to encircle pertinent features on the screen, as shown in Figure 15. Too bad if a user wanted to do something unexpected in the midst of a task. This overly controlling approach to Help made it difficult for users to get an overview of a task, so had a negative impact on learning. While coach marks could be helpful to novice users who just wanted Help to walk them through a task, while using an unfamiliar user interface, they weren’t so helpful to more experienced users who perhaps needed just one bit of information to successfully complete a task. Apple did not incorporate Apple Guide in Mac OS X.
Recently, I heard about a very similar Help system being designed at Google. As Sir Winston Churchill once said, “Those who fail to learn from history are doomed to repeat it.”
Always Safeguard Users’ Data
The most egregious instances of poor interaction design—whether through errors of commission or omission—are those that result in users’ losing their data, including the following:
not recovering users’ data when an application crashes or hangs
placing Delete or other destructive commands in locations where users may slip and click them inadvertently
not confirming destructive operations before completing them
not remembering users’ settings during a work session
not saving users’ settings across work sessions
In The Humane Interface, Jef Raskin wrote, “The system should treat all user input as sacred.” That’s the standard interaction designers should always work to achieve.
Don’t Destroy Users’ Data
Design for recoverability. Since most major applications today tend to crash or hang with annoying frequency, it’s essential that you include a failsafe mechanism for saving users’ data in your UX requirements. Of all the desktop applications I use most frequently, only Microsoft Word does a good job of recovering my data when it crashes—not perfect, but quite good. When users reopen Word after a crash, it displays all of the files they were working on, including most of their changes since their last save. Both Google Sites and Google Docs save users work automatically, though perhaps not quite as frequently as they should. Figure 16 shows Google Docs automatically saving a document. The Saving… status message is transitory, but the saved on [date][time] by [author] status display always appears at the top of the page, so users can reassure themselves that their documents have been saved.
Unfortunately, when Dreamweaver or Photoshop crash or hang—not uncommon occurrences—I lose all of the work I’ve done since I last saved. At the prices Adobe charges for its applications, they should be more stable and implement features that prevent users’ data from being lost when they do crash.
If you include an autosave feature in an application, be sure to specify that autosaves should occur in the background, so they don’t prevent users from proceeding with their work.
Prevent Destructive Errors
Do not place Delete or other potentially destructive commands or buttons in close proximity to other controls. If you place such controls too close together, users are likely to slip occasionally, inadvertently clicking the wrong control. Figure 17 shows the popup menu that appears in Dreamweaver when a user Ctrl-clicks a CSS style. In this popup menu, the Cut command is immediately below the frequently used Apply command, with no intervening separator bar, making it all too easy for a user to make a catastrophic slip and wipe out a CSS style that may have taken hours to create and debug. And, of course, because it’s a Cut command, not a Delete command, no confirmation box appears. Thus, if a user doesn’t immediately realize what has happened, the user’s work is destroyed.
Figure 18 shows the Upload Photos dialog box I designed for scanR, in which the Remove button is well segregated from other controls.
When a user chooses a command that can destroy the user’s data, always display a confirmation message box similar to that shown in Figure 19.
Remember Users’ Settings
Since it’s not unlikely that an application might crash or hang, it’s essential to specify that an application should save settings when a user changes them, not when the user quits the application. Dreamweaver for Mac OS X provides a case in point. Somehow or other, it gets into a state where it no longer displays the Files tab in the Files panel on the right, as shown in Figure 20. To get the Files tab back, a user must choose Window > Workspace Layout > Default, then resize all of the windows and close all unwanted tabs and panels. Quite a rigmarole to go through. But Dreamweaver doesn’t save the user’s changes until the user quits the application, so if it crashes in the meantime, the user will have to go through the whole rigmarole all over again.
Comcast’s Fancast Browse TV Listings page, shown in Figure 21, does a poor job of saving users’ settings both within and across sessions. For example, if a user chooses a time on the Time drop-down menu, then chooses a different day, Fancast resets the time to the current time.
The site also fails to consistently retain a user’s ZIP code across work sessions, which is necessary to display TV listings for the proper channels. About a year ago the site went through a major reimplementation. At that time, lots of things that used to work perfectly ceased working, including the site’s favorites feature, which wasn’t included at all. After a major uproar from users, Comcast apologized for removing the feature and brought it back about a month later. When a cable system offers over 200 channels, it’s not a trivial effort to go through all of them to determine which ones to favorite and, thus, move to the top of the listings. When the favorites feature came back, the users’ favorites data didn’t. After a site had destroyed your data once, would you trust it not to do it again and go to the trouble of recreating your favorites? Never violate your users’ trust by destroying their data or failing to save their settings.
This application has been in this buggy state for almost a year now. As UX professionals, part of our responsibility is to ensure applications don’t get released when their reliability is so poor. If they do for some reason, it then becomes important for us to make sure bugs that result in such a bad user experience get fixed.
Interaction designers are also users, so it shouldn’t be a big stretch for us to feel empathy for users when considering the kinds of design errors I’ve described in this column. Always put yourself in your users’ place. What are the gotchas in the applications you’re designing that could cause your users unnecessary pain or risk destroying their data? Do everything you can to remedy such problems. Are there other examples of such fundamental design errors you’ve encountered that you’d like to share in the comments? By sharing our own interaction design pet peeves, perhaps we can prevent our peers from making mistakes that are similar to those that plague us and our users.
Founder, Publisher, and Editor in Chief of UXmatters
Silicon Valley, California, USA
With more than 20 years working in User Experience at companies such as Google, Cisco, WebEx, Apple, and many startups, Pabini now provides UX strategy and design consulting services through her Silicon Valley company, Strategic UX. Her past UX leadership roles include Head of UX for Sales & Marketing IT at Intel, Senior Director of UX and Design at Apttus, Principal UX Architect at BMC Software, VP of User Experience at scanR, and Manager of User Experience at WebEx. Pabini has led UX strategy, design, and user research for Web, mobile, and desktop applications for consumers, small businesses, and enterprises, in diverse product domains. Working collaboratively with business executives, multidisciplinary product teams, and UX teams, she has envisioned and realized holistic UX design solutions for innovative, award-winning products that delighted users, achieved success in the marketplace, and delivered business value. As a UX leader, she has facilitated conceptual modeling and ideation sessions; written user stories; prioritized product and usability requirements; established corporate design frameworks, standards, and guidelines; and integrated lean UX activities into agile development processes. Pabini is a strategic thinker, and the diversity of her experience enables her to synthesize innovative solutions for challenging strategy and design problems. She is passionate about creating great user experiences that meet users’ needs and get business results. A thought leader in the UX community, Pabini was a Founding Director of the Interaction Design Association (IxDA). Read More