“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
- technical constraints
- business goals
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, shown in Figures 3 and 4.
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.
