Wednesday, November 28, 2007

7 Critical Considerations for Designing Effective Applications, Part II

Second in the series on good design principles ...

"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."    (Continued via UIE)    [Usability Resources]

0 Comments:

Post a Comment

<< Home

<< Home
.