7 Critical Considerations for Designing Effective Applications, Part II

(Editor’s note: In Part I, Jared talked about the first three considerations: designing for satisfactory detail, designing recognition and appropriate feedback, and designing for the user’s previous experiences. You can read part Ihere.)

Our user, a regular business traveler trying to quickly book a flight, was reviewing a selection of flight options supplied by USAir.com. While there were plenty of flights, the user felt these weren’t meeting her needs—either the flight arrived too late or made risky connections. Thinking leaving a little earlier would give her better flights, the user tried hitting the back button only to receive an error message.

Hitting the back button is a cardinal sin in many web apps. The stateless browser often can’t deal with a user’s desire to back up and try again, resulting in cryptic messages spewing technology terms like POSTDATA and server refresh.

Yet, the desire to try again is one of many things a web application designer needs to be aware of. As we’re designing applications, it’s important we remember these critical considerations for creating effective designs:

4. Design for Flexibility

Things don’t always go as planned. We hope our users will get things right the first time through, but it doesn’t always work that way.

Sometimes it’s not that the user has made a mistake, but that they just didn’t get the result they wanted. Our traveler wanted to check out different flights, so she needed a way to broaden the search.

Designs have to be flexible. Users want a way to experiment. Over at Kayak.com, the criteria for the flight are all in the left margin. Want to limit the selection to flights arriving before 6pm? Two clicks and it’s done. Want to see only non-stop flights? One click and there you are.

We’ve discovered users rarely hit the back button unless they have a reason to go to a previous point. Designers can eliminate that desire to go back by giving users control mechanisms on the current screen. At a minimum, a prominent ‘undo’ function allows the application to reset itself without the ugly browser error messages.

Flexibility shows itself in other ways, too. In one design iteration, Amazon experimented with Ajax pop-ups when the user hovered over a book title. The pop-ups, which gave users more information about the book, popped up almost instantly as the user waved their mouse.

Unfortunately, making the pop-up disappear was more difficult. Amazon only supplied a very tiny Close Window control on the opposite end of the window. The control was both hard to find and hard to hit.

Designing for flexibility means giving users an easy way to reverse what they’ve done, whether that’s changing the parameters of a product search or closing a window they’ve opened.

5. Design Defensively

Imagine asking a store clerk about a pair of tan slacks in your size and hearing this response:

“I’m sorry, but the item you specified is not available. Please try again, selecting a different size or color.”

After two or three repetitions, you’d probably pull back and slug them.

Yet, sites do this all the time. They tell us we’ve neglected to include a number in our password or we’ve added an extra space in our credit card number. They inform us we’ve left a mandatory field blank or created a configuration that can’t be fulfilled due to conflicting requirements.

At a recent visit to Cisco.com, we were asked to create an account so we could peruse the products in the company store. (Don’t get us started why we needed an account just to look at the products!) Only after entering our account name (and filling in 10 other fields on the same form), did the site inform us the account name must contain a minimum of nine characters.

There was no hint of this before we submitted the form. The designers felt the need to keep the length requirement a secret from the users.

Contrast this with Blinksale.com, a site to help sole proprietors and small businesses with their invoicing. As you type in a potential Blinksale ID, an Ajax-produced message tells you immediately if the ID has the right number of letters and is available for your use.

The Blinksale designers have designed defensively, preventing the error from happening in the first place. We recommend teams go through all the error messages in their system and ask, “How could we create a design that eliminates the necessity to issue each message?”

Explicit error messages aren’t the only place where designers need to think defensively. Defending against interruption is another dimension of the problem.

Interruptions happen all the time. Users are working through an application, when, suddenly, they need to take a phone call or look up something on another page. When they return, they forget where they were or have lost their place in the application. Now they are faced with starting the process over again.

Over at Google Docs, they automatically provide a frequent “auto-save” capability. As users work on their documents, the system frequently stores any changes. If the user steps away from their machine and come back later, the document is as they left it, even if they closed the browser session.

Designing defensively is about considering the “gotcha” points in an application and creatively building defenses to protect the user.

6. Design for Appropriate Frequencies

The user stared at the question: “When did you graduate school?” A simple question for sure, yet he didn’t know how to answer it. Was it asking about high school, college degree, his masters’ degree, or the PHD he almost finished? Did it want only a year or did it want a year, month, and day? How exactly should he answer this?

Unfortunately, the answer was important. If he answered it wrong, the bank, where he handled all his finances, wouldn’t let him in to work with his account. Even if he got the right school, but entered the date in the incorrect format, he’d be barred from access.

To make matters worse, this wasn’t the first time he answered the question. Several years ago, when he first established the account, he answered this exact question. It is that answer the system is now requesting. Only now, he can’t remember what he’d originally entered.

A person may only use some applications, like a security authentication application, once every few years. That same person may use other applications multiple times per day.

Our user is in charge of ordering materials for the construction of a 45-story skyscraper. He uses their requisition system three to five times every working day. Since the construction company can’t store all the necessary materials to build a skyscraper on site from the start of the project (as it would take an additional skyscraper to store the stuff), he orders it as the project progresses, ordering only those materials necessary for the next few days of work.

The requisition application needs to be designed for frequent use, giving the purchaser shortcuts to check inventory status, repeat materials, and order massive quantities (like the toilet seats required for the building’s 950 bathroom stalls). This is not your father’s Home Depot web site.

When users interact with a design repetitively, they start to commit things to memory, such as terminology, functionality locations, and command sequences. Frequent users become frustrated when these things are hard to memorize.

However, infrequent users can’t rely on memory and need visual clues. Had the bank authentication prompt been more specific (“What year did you graduate your high school? [Example: 1978]”), our banking customer would’ve likely breezed through the security check. Unfortunately, the bank’s design required the customer to remember an exact text string they entered three years earlier. When they didn’t, the system locked them out of their account.

Design teams need to ask about the frequency of functionality and design appropriately. When they have mixed audiences for certain functionality—some features frequently used by some users, but infrequently accessed by others—the designers need to take extra care to ensure each audience gets what they need from the design. Frequent users want efficient motion and easy to memorize infrastructure. Infrequent users want visual clues to help them understand what to do next.

7. Design for Minimalism

Just because you can design a widget doesn’t mean you should design that widget. Over at WatchThisNext.com, the DVD recommendation service has movie viewers specify their feelings about a given movie by dragging the movie’s image into one of three boxes: Loved It, Haven’t Seen It, or Loathed It. Once the user starts dragging movies to the appropriate boxes, the site starts recommending new movies for the viewer.

All this dragging and dropping takes time, energy, and a certain amount of coordination. It turns out it’s completely unnecessary. The designers at Netflix provide the same functionality, without the mouse flailing. A simple method of clicking on one of five stars or pressing a lozenge marked “Not interested” indicates the same information without the thrashing about.

There’s no better call for minimalist designs than the recent infestation of carousels now infecting many web sites. Amazon, for example, has installed a carousel to display ten or so products on the shopper’s wish list. The user clicks on the forward or reverse buttons to move a simulated 3-day turntable of products to bring a product of interest to the front. Enjoyable to play with and interesting cinematic effects make it fun to play with for a few moments. However, the novelty quickly wears off and the difficulty of interacting with the widget becomes quickly apparent, as users accidentally select the wrong item or can’t get enough detail to know what they’re viewing.

Interesting effects can help an application’s design. In the popular bookmarking service, Delicious, users type tags for a bookmarked page to help them find that page in the future.

The designers at Delicious have added a suggestion feature, where the system offers potential tags, based on previous entries and other users’ choices, to help enforce a consistency from one tag usage to the next. This sophisticated implementation provides substantial value to the user. Yet, its minimalist approach gives users power without overwhelming the interactions.

Critical Considerations

Designing applications today is a complex process, with both client and server constraints to account for, complex business rules to accommodate, and the demands of an ever-more sophisticated audience to meet. Yet, as much as things change, some things remain the same.

The seven considerations we’ve talked about are critical for the design of effective applications, no matter the underlying technology or business constraints. Designers need to regularly step back from their designs and review the list, to ensure they’re heading down the right path.

(Editor’s note: In Part I, Jared talked about the first three considerations: designing for satisfactory detail, designing recognition and appropriate feedback, and designing for the user’s previous experiences. You can see the first part here.)