UIEtips -- 11/20/01
People Search Once, Maybe Twice

Contents:

- Letter from the Editor
- People Search Once, Maybe Twice
- Letters from Readers
- Upcoming Courses
- Case Study: Using Flash for Web Applications

--> Letter from the Editor

Greetings,

We've been busy in the laboratory with our most recent study --
observing people trying to shop on apparel and home goods sites for
more than 130 hours. In the process, we've learned quite a bit about
how people search for content, what is important on home pages, and
the patience people have interacting with frustrating web sites.

One of the most interesting things we've seen is how people react to
shipping prices. Now, we all know that when folks are surprised by
shipping, they abandon their shopping cart. However, not all shipping
is the same and we're just now beginning to see some of the subtleties
in differences in design.

For example, Eddie Bauer separated their shipping and handling into
two separate charges. Even though the combined cost was often less
than what the same users would pay on other sites for "just shipping,"
the users refused to pay the extra handling fee and gave up on the
transaction.

We saw plenty of examples of users refusing to buy products because of
small shipping charges, then being completely happy to purchase a
product with a larger shipping charge.

Shipping charges represent the ultimate in user frustration. They are
a price we pay for ordering online.

What intrigues us about shipping charges is that they are content that
upsets users -- sometimes, but not all the time. Different designs of
this content seem to consistently evoke different user behaviors.

If we can understand why some shipping charges are acceptable while
others are unacceptable, it will give us great insight in how users
perceive subtle differences in content presentation. And this will
help us understand how to increase the usability and reduce the
frustration of web site designs of all kinds.

By the way, if you're going to be at the upcoming Web Builder
conference in New Orleans (http://www.webbuilderconference.com/) at
the end of this month, come find me. I'll be there on the 28th in the
Making the Web Usable workshop with Andrew Chak and Kelly Goto.

We hope you enjoy the rest of this issue of UIEtips. As usual, if you
have any questions or thoughts, just pop us a message at uie@uie.com.
We'd love to hear from you.

Jared M. Spool

- o - o - o -


--> People Search Once, Maybe Twice

Lately, we've been focused on the effectiveness of Search. When
looking for content, users often end up using the search engine. In a
recent study, we observed that users only found their target content
34% of the time with Search. (This is compared to 54% of the time with
categories.) We wanted to know why.

It turns out that one reason that users don't succeed is that they
really don't try to. In looking at the search patterns of 30 users
shopping on e-commerce sites, we focused on those search attempts
where Search failed to help the user find a result.

What was interesting was that 47% of the users who failed only tried
the search engine a single time. Another 30% tried twice. Less than
25% tried more than twice to get the search engine to produce a
successful result.

Now, the designers of many of the sites we tested went to great
lengths to get users to continue searching. They put in encouraging
search tips that said "Try a new search using different terms."

However, we did not see any evidence that these tips encouraged any
user to search again. They pretty much assumed that the first (maybe
second) try was the best they were going to get.

For example, Bed Bath and Beyond's site encouraged a user who was
searching for curtains to "use a generic term, like 'pans' or 'coffee'
to broaden [his] search and increase the number of items found." What
is a generic term for curtains?

These results indicate that designers get one, possibly two chances to
help users find their content with Search. If most of the users don't
find what they want in the first try, it doesn't seem likely they will
ever find it.

By the way, these results aren't unique to e-commerce sites. For
years, we've been seeing these results on intranets, corporate and
institutional information sites, and any other type of site with a
search capability. It's just nice to have the concrete data from our
e-commerce study to prove what we've long suspected.

More and more, our ongoing research is telling us that Search has to
be perfect. Users expect it to "just work" the first time, every time.

(As you read this, Erik Ojakaar is knee deep in compiling our latest
research about Search in a brand new report -- keep your eyes peeled.)

- o - o - o -


--> Letters from Readers

Recently, we published an article on our site (Users Decide First;
Move Second) about rollovers, flyouts, and dropdowns. (See
http://world.std.com/~uieweb/Articles/what_they_want_article.htm)

Many folks asked us if, as users became more experienced with a site,
they would "learn" to find the hidden information in these design
elements. For example, Gary Zimmerman commented:

Loved the article and the research. Good to know. But not, I
think, particularly significant with respect to design. Here's
why:

"once users realized there was more information available to
them, they stopped and re-evaluated the screen."

You acknowledge that in this article, but then go on to discount
it, and say that it "disorients" users. Yeah, maybe... for about
three seconds. Once you learn how a site is designed, you adapt
to it. Too many usability studies discount the fact that people
learn and adapt.

Drawing conclusions or making "design rules" based on such
research caters to the lowest common denominator of users who
simply don't learn or adapt after their first experience of the
flyouts. These users are the minority, and are probably NOT who
many sites are targeting anyway.

We agree with Gary that we shouldn't make design rules based on this
research. That's not our purpose.

Instead, we hope that research like this will help designers know what
to look for when watching users on the site. By pointing out the
potential problems when users encounter these design elements,
designers can watch to see if those problems exist on their site.

If the problems do arise, we can turn to the research to see what
potential solutions exist. And if they don't, well, don't make any
changes whatsoever.

After all, the goal is for users to get what they need from the site.
If they are successful at accomplishing *their* goals with the current
design, then the designers should not change it, no matter what *our*
research says.

Case Study: Using Flash for Web Applications

We came upon an interesting use of Flash recently.
http://reservations.broadmoor.com

What caught our attention was how the designers used Flash to create a
fully interactive, data-driven reservation system.

We've been very interested in this topic lately. Christine Perfetti
and Matthew Klee wrote in their recent report (Making the Best with
Flash, http://world.std.com/~uieweb/flash.htm) about the key
attributes of Flash that would contribute to such an application.

So, imagine our delight when we finally saw one. Now, granted this is
obviously a first cut at this approach, but we think it's a great
start.

Try selecting multiple dates. Instantly, the rooms available for that
period highlight with the prices for the total stay. Clicking on the
Deluxe room gives a picture and a description appears. Extend your
stay by a few more days and see when the prices go up.

It's a little rough around the edges and probably requires more
"experimentation" than people want when trying to book a room, but
it's an interesting start. (We feel we should encourage designers to
try novel approaches like this, just so we can learn and grow!)

This implementation has given us hope for Flash's role in web
applications. HTML is extremely limiting in its capabilities,
particularly when it comes to the sub-second response time that
really needs to happen. (The Making the Best with Flash report talks
about how sub-second response contributed to the success of the Lee
Fit Finder and Timbuk2Design's Bag Builder applications.)

All you have to do is compare the interaction on this screen to the
interaction at a major hotel chain, like http://www.marriott.com, and
you'll instantly see why we're excited about the pote
ntial that this
implementation offers for web-based applications.