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 potential that this implementation offers for web-based applications.