Originally published: Oct 22, 2007
(Editor's note: This is the first part of a two-part article, delivering the first three considerations. Next week's article will sum up with the remaining four considerations.)
Our user, a world-traveling executive with a fondness for the finer things in life, showed tremendous interest in WhiteTie's brand new personal concierge service. While visiting WhiteTie's web site, the executive carefully reviewed the content to learn more about how the service worked and what she'd get for her (very pricey) annual fee.
She was attracted to a section in the center of the page, appropriately labeled "What We Offer". Here, our executive found the encouragement to click on links with labels like "Northwest Airlines", "Restaurants", "Nightlife", and "Travel & Services". The site's copy promised her they could get exclusive restaurant reservations and tickets to local events, which, since she liked to impress her clients and guests, excited her.
Though the site told her to click on the links to learn more about their offerings, the site failed to actually tell her any more. She expected a full page for each service detailing, for example, which restaurants they could get reservations in, how it worked, how many days in advance she needed to make the reservations, how they handled last minute arrangements, and the dozens of other questions that had been populating her thoughts while exploring the service.
Yet, just because we can provide all these tools doesn't mean we'll automatically build applications users can use to achieve their goals. In fact, it's very easy to become distracted by the technology and forget the basics of interaction design, leaving the user with a slick application that doesn't meet their needs.
As we're designing our applications, it's important we remember these seven critical considerations for creating effective applications:
While it's very likely our executive would enjoy the WhiteTie service, the site didn't provide enough detail to help her decide if they really did what they said they would do.
Almost every application requires the user to make choices. It's up to the designers to ensure they provide enough information to make the right choice, without overwhelming the user with too much information. They need to describe the information using language familiar to the user, not filling with jargon or technical terms the user can't understand.
When a design asks a user to make a choice, the user clearly needs to know what the differences are between them. If the application has further steps, the user often needs to know there are further important activities (such as determining shipping costs or entering payment information), so they can plan accordingly.
Ajax and Flash interaction can make the display of information more vibrant and enticing, taking advantage of cinematic effects and providing new content without time-consuming page refreshes. However, if the design doesn't allow for enough content, the advantages of the technological enhancements are overcome by the disadvantages of missing information.
For example, while the Gap.com's QuickLook product windows let users quickly get critical information about their products, the product overview is a small text field often hidden behind a tab containing all but the briefest of descriptions. This doesn't really give the Gap's content provider an easy way to get the enticing features and benefits of their products to prospective buyers.
The best designers focus as much on the detail of the information they're providing as they do on the presentation methods. They're constantly evaluating their designs, asking, "Are we giving the user enough information to successfully complete their objective?"
There's no arguing that sophisticated interaction techniques, such as drag-and-drop, click-and-pull scrolling, or multiple selections, can enhance the user's experience. However, they are rarely presented with any visual clues about their existence. Unless users are very experimental (which they typically aren't) or have a friend who will show them the advanced feature, they are unlikely to discover it themselves.
It is important to provide visual clues so users can recognize these advanced manipulation techniques. These can take a myriad of forms, from pop-up messages to animated demonstrations, and teams need to experiment to see which are most effective for their users.
Similarly, designers need to ensure users know something has just happened. For example, on Hotels.com, the designers helpfully provide sliders to help narrow price ranges, hotel quality, and user ratings for the hotels presented in the site's search results. However, the controls are so quick and the changes are so subtle that users often miss the result changes, thinking nothing has happened and looking for a missing "update" button.
The best teams understand these advanced interaction techniques will require visual feedback so users can recognize how they work and what they've done.
Every few months we hear someone proclaim, "Things online should work just like their real-world counterparts. Why should users learn new ways to interact with common objects? An online book should act just like a real-world book."
Unfortunately, objects on the two-dimensional screen aren't the same as their three-dimensional counterparts and probably shouldn't behave the same way. While it's cute to show an online product catalog as a series of pages, just like the catalogs we get in the mail, it quickly becomes annoying to have to turn pages by grabbing the corner and dragging across the screen (otherwise the page falls back like a real page would). Seeing the corner of the page curl up might delight the user the first time, but the real-world replication is likely to become tiresome.
Instead of thinking in terms of the "real world," successful designers make sure they thoroughly understand their users' previous experiences. If they are requiring substantial tabular data entry and they know their users are experienced with Microsoft Excel, then making their tabular system interact that way is helpful. However, if they know users are unlikely to have previously used Excel, then they ensure that data entry tools don't require knowledge of Excel's more idiosyncratic behaviors.
This is particularly true when designing a suite of applications. If you know your users are likely to interact with more than one application in the suite, having them behave the same can be very helpful. However, if the different applications are designed for different users, having common behavior (also known as "consistency") is far less important than having each application take advantage of the experiences of their own individual users. A tool for accountants probably shouldn't behave consistently with a tool for graphic designers, even if they are part of the same family of tools.
In our research, we consistently see the best teams regularly conducting thorough research on their user's previous experiences, so they can leverage that information in their designs.
(Editor's Note: In part 2, Jared will talk about the four remaining considerations: designing for flexibility, defensive behaviors, appropriate frequencies, and minimalism. Stay tuned for next week's installment.)
One of our go to people when it comes to designing applications is Hagan Rivers. She is a powerhouse of information. That's why we asked (actually begged) her to give a full-day workshop at the User Interface 16 Conference, November 7-9. Hagan's full-day workshop, Simplifying Complex Applications will help make your applications simple and intuitive.
Read related articles: