Virtual Seminar attendee Paul Baker asks:

“What sort of contextual research might you do when designing a social site?”

We have found that research methods won’t change much when designing a social site, but the line of inquiry will. So we tend to use tried-and-true research tools: interviews, user tests, and field studies.

The big difference when moving to social design research is the focus of observation: in addition to wondering what activities people are doing and what is necessary for their completion, we increase focus on the social interactions that influence why they’re doing so.

A major insight of social design is that when people make decisions they rarely act alone. Their social groups, friends, and family have a huge influence on their behavior. As software becomes more a part of our lifestyle, social influence will play a larger part in how we use it.

This shouldn’t be surprising as it is easy to think of the last recommendation, suggestion, or pointer we received. Thus, these simple items are the object of our inquiry.

Here’s an example of how we might focus an interview on social aspects:

Imagine you’re interviewing someone about looking for an apartment on the Web. You ask them the usual questions, where they go, what sites they visit, what information is important to them, what they like and don’t like. Most of the discussion will deal with what is important to them as they fulfill this activity.

At some point, unless the person is truly anti-social, someone else will enter into the conversation. Maybe it’s their brother who recommended they search in a certain neighborhood in the Back Bay of Boston. Or their boyfriend who says to make sure everything that in the apartment is fixed before moving in. This is where the social part comes in.

Most of the time these people are treated as outsiders to research. They are flat characters, so to speak, who show up only for a minute. But when thinking about this from a more social perspective, these people are primary actors because they’re influencing the person as much as any software is. They are helping to define why the person is doing what they’re doing.

So the line of questioning turns toward them. We ask more about their influence. Did you take your brother’s suggestion? Do you often take his suggestion, or just in cases involving this subject? What makes him such a good person to listen to concerning this subject? Whose suggestion did you end up going with, and why?

In addition, we want to get a sense of how they communicated. Was it over the phone? Email? IM? During a face-to-face conversation? Did they get a recommendation from a blog? How are they getting their information?

Using questions like this help us figure out how this person assigns trust to those around them. It also helps us tease out important factors in their decision making process that involve other people.

Once we have a clear picture of how a person makes decisions in a certain area, we can compare them with others. We’ve found that there are usually trends in how this works. These trends feed into our design.

So if we were creating a site to support this activity, we might create a “apartment hunters” model in our software that allows people to connect with landlords based on criteria their social network suggested was important. We also know that apartment hunting doesn’t happen frequently, so we might lean away from a “friends” feature for the time being. But we might also focus more on archiving information over a longer term so that folks coming to the site don’t have to tap into their social network as much, instead relying on the accumulated wisdom of others.

This is just an example of how this might work. Your research will probably take you in some other, more interesting, direction. The key to doing social design research is to figure out the relationships between users and their social group, and how that affects their behavior and decision-making.

The runaway successes of YouTube, MySpace, and Flickr have completely changed the landscape of design. One huge change is the rise in socially-enabled web applications, applications that connect users in new and more explicit ways. Witness the trend of “going social” on news sites, where they give their community the ability to comment on and even participate in the news. The design team behind the USAToday.com web site, for example, recently enhanced their site with new social features including comments, reviews, discussion forums, and the ability to make recommendations. Just this past week ABCNews did the same.

So what are the core benefits of making this change? Why invest in social features? Although the benefits will vary depending on the business and the audience, here are some core benefits of investing in social features that apply broadly across many areas:

Amplify Customer Opinion

Humans are social animals. Therefore, it is likely that there is social activity happening around your content or service whether you want it to or not. People are sharing their stories, complimenting about what’s good, complaining about what’s bad even if you aren’t listening. By adding social features to your web site, you’re enabling them to do it in a way that you can listen to.

Companies with strong products users love will help them share those experiences with others. For example, something as simple as a “share this” feature on a news site will allow people to let someone else know about what they find interesting…amplifying their enthusiasm about it.

Similarly, companies with products users hate will have that amplified as well. If someone posts a horror story like Jeff Jarvis did in his famous “Dell Hell” blog posts, lots of people will get wind of it.

This is a crucial situation brought to bear by social features…when users complain you are given a clear choice: either ignore that feedback or act on it in a positive way. Companies that treat it as an opportunity for improvement will probably improve. Companies that treat it as a public airing of dirty laundry will probably suffer…

Data, Data, and more Data

Perhaps the least talked about benefit of social features is that they are wonderful precursors to a data-driven design strategy. Every time someone saves, shares, or comments on something, you have more data to go on regarding what they find valuable.

We’ve been doing this at UIE for some time. When someone shares an article at UIE we count it. The 10 most-shared articles on UIE.com, therefore, tell us what our readers find “share-worthy”. This is an important metric for us, as we use it to plan future pieces.

The benefits of data-driven design are huge for teams having trouble separating personal opinion from project decision-making. (we find very few teams where this isn’t the case). When decisions are based on actual data, they become much easier to make. Politics fall by the wayside and good design practices often emerge as a result.

Reduce Support Costs

Social features help reduce support costs by recording help issues publicly and letting customers help themselves. Talk to any support call specialist and you’ll find that their lives can be very repetitive, answering the same questions over and over again. This doesn’t have to be the case. When you add social features like support bulletin boards, for example, most of the conversations are recorded for all to see. Users can then search for the topic that they’re interested in, and if someone has had a similar experience previously they can start reading there. Bulletin boards, of course, have been around even longer than the Web itself. But making them public and searchable makes them valuable resources for everyone.

Additionally, systems like this allow users to help themselves by giving them the power to answer other people’s questions. Sometimes the users of the products are as knowledgeable about a product as the support people are. Social features allow them to help out and make the community stronger as a result.

Some sites like Apple.com’s Support Site have more advanced features whereby people can rate the responses they are given to their questions. That way, if one response by the community really helped the person who asked the question, it will be flagged and easily found by future readers. This helps users filter out bad responses, further reducing support costs.

Engendering Trust

Opening up communication channels with customers engenders trust, and that can be priceless. Sites that might otherwise be seen as closed-up and insular can open up communication channels where none existed before.

When you implement social features, it is a signal that you care what people have to say. It declares “we are here and we’re listening” attitude. Putting comments on a news article, like USAToday.com did, suggests that they are interested in letting people voice their opinion about the news.

Sometimes just telling someone their opinion counts is enough to engender trust. They’re much more likely to give you the benefit of the doubt when the sky turns dark. Of course, backing up your features by actually listening is necessary for the long-term health of your site, so the activity doesn’t end with implementation.

Going Social is a Long-term Experience Design Strategy

In addition to the explicit benefits for the site owner, implementing social features means building a community around shared experiences. The notion of “shared experiences” difficult to define, but the benefits of increased participation and caring are clear. People respond best to communities where they believe they’ll find like-minded people and where they feel their ideas and opinions matter. This trust is the real benefit of social software.

Therefore, adding social features isn’t so much a leap of faith as it is an investment in a long-term experience design strategy. Of course, the costs of building social features aren’t negligible and the return on investment might not be immediate. It may take months before a social support site starts to take over support activities from a call center. Therefore, it is critical to plan out the maintenance and support of social features over time.

When all the benefits are combined together and your customers now see your site as being run by human beings instead of nameless droids, and they feel invested in the site, you’ll realize that social features are only surfacing what exists already, and it’s really just a human-centered way forward.

Today’s homepage, a page cluttered with ads for the new movie Red Line, is just another in a long line of disorienting, disquieting, overly-saturated designs that makes you wonder: “Why? Why on earth would MySpace create a billboard for Satan?”

(click for full-size screenshot)

It’s no wonder that every time we get talking about MySpace some very passionate conversation ensues. It is almost impossible to see through the visual clutter of the site to reveal the value that people are actually getting out of it.

Bad Design, Great Conversation

That’s why I think MySpace a great thing for design. Not because the homepage makes one’s head hurt, but because it so obscures the value that its members are getting that it always leads to passionate conversations. It gets graphic designers riled up, interaction designers in a tizzy, and product leads simply shaking their head.

Just yesterday, Jared and I were in a meeting with a design team and the subject of MySpace came up. Boy did the conversation begin to move then! Everyone went from a caffeine low to a can’t-get-a-word-in edgewise high. It was fabulous. Everyone had an opinion, and everyone was involved. That in itself is valuable.

What often happens at this point is that the notion of value has to come to the forefront for MySpace to make sense. We can’t imagine value coming from something so ugly, so we have to rely on asking actual MySpace users to find out why they’re so connected to the site. If you have done this or ever have the chance to, do it! You’ll find it incredibly interesting. The conversations that I’ve had with MySpace users has really changed the way I think about design…as well as the entire value proposition of social software.

To that end, ethnographers and usability folks, who study the actual behavior of people, are fascinated by MySpace. It’s like studying an alien civilization. The site breaks all the rules. Our common notions of design just don’t apply. It’s truly another world.

This is a good thing! The frustration we feel when looking at MySpace is a catalyst for evaluating our own design practices. Are we making too many assumptions based on how we personally feel? Are we in tune enough with the people we design for? Are we focused too much on visuals and not enough on other ways of providing value? Are we not targeting the right population? The questions that MySpace forces on us are valuable, enlightening, and always controversial.

So what do you think? Do you agree that MySpace is good for design? Or do you see it as a blot on the face of the Web?

At UIE we’ve been watching social sites for a while now, and we’ve seen many social features, including the ones added by USAToday, become commonplace over the last few years. It comes as no surprise that large organizations are seeing the value of connecting their users in ever-beneficial ways like they’re trying to do at USAToday.

But even though big sites adding many social features at a time draws lots of attention, there is one site that is way ahead of everyone else, offering a myriad of social features that eclipses the field, hands down. That site is Amazon.com. Now, we’re not feature counters by any means, but we have seen the features on Amazon provide a tremendous amount of value to users during testing of the site. The product reviews, for example, are a huge advantage Amazon holds over other e-commerce sites…people really trust the reviews there compared to everywhere else. I wrote about this phenomenon in The Amazon Effect.

But just how social is Amazon, you ask? Well, pretty darn social. In a slide from the presentation I gave at the UIE Web App Summit, I outlined 11 social features on the iPod product page at Amazon. The slide wasn’t very effective, however, as it only contained small screen-shots of the features laid on top of one another. It didn’t show the scope of what Amazon was doing with social features.

I’ve now found a better way to visualize what Amazon is doing. The following is a screen-shot of the entire iPod product page at Amazon, with 16! social features highlighted throughout the page:

This is a clear indication that Amazon is making a huge investment in social features…and suggests that maybe it’s Amazon who should be getting the big press. Part of the reason why they don’t receive lots of press, of course, is that Amazon releases features one-at-a-time…slow enough that it creeps up on us.

1. 5-Second Tests: Measuring Your Site’s Content Pages
2. The Quiet Death of the Major Re-Launch
3. What Makes a Design Seem ‘Intuitive’?
4. The KJ-Technique: A Group Process for Establishing Priorities
5. Branding and Usability
6. The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site
7. Using Ajax for Creating Web Applications
8. Testing Web Sites with Eye-Tracking
9. The Truth About Download Time
10. Testing the Three-Click Rule

We have about 100 more articles in our article archive!

Writing on Digital Web, Luke points out that the two have a lot in common:

“In a self-service retail world (present in most physical stores and just about everywhere online), the back-of-pack information plays the role of surrogate sales associate. It outlines the advantages of a product and often includes explanations of how to best utilize them. In other words, it tries to finalize the sale with peripheral messaging that supports the front’s central message.

In many web applications, this role is filled by product tours. The most common product tour is an illustrated page or set of pages that explains what can be done with an application, and shows features in action through representative screen shots.”

Lots more in the article itself: Packaging Design for Web-based Products

Still, when we use today’s web apps, there is a clear distinction between online and off. If we aren’t online, we simply can’t use them. Our data resides on a web server (not our own machine) and the only way to access it is to actually communicate with the server in real time. To do that, we must be online.

Things are changing, however, albeit slowly. David Malouf, who is co-presenting a full-day seminar: Designing Powerful Web Applications using AJAX and RIAs at our upcoming Web App Summit, pointed me to a recent demonstration of a web app that promises to let us do just that: have our cake and eat it, too.

The application is a web-based office product called Zimbra. It includes a web-based email client, just like we’re used to with Yahoo Mail, Gmail, or Hotmail, but it also gives you the ability to work offline. From a recent blog post demonstrating that ability:

“The design goal is to have the same user experience with Zimbra both online and offline. Technically the Zimbra Offline client is the same AJAX client UI but now connecting to a local sync’d cache of the data and more importantly the ability to search, tag, organize, etc without network access. The two way sync of mail, calendar, contacts, and documents will allow Zimbra user’s to take their collaboration data together with the Zimbra AJAX experience with them on the road or in places without a network connection and when they come back online – all of the changes made while offline (like composing, deleting, moving, creating messages, contacts, events or folders) are sync’d back to the cloud. Just like traditional offline mail clients – messages pending to be sent are stored in an Outbox where you can edit and view them until re-connected.”

That’s quite a design goal, to make the online/offline distinction disappear! But it’s a vision of the future, (and I’m going out on a limb on this one ) this will certainly be a feature built into many more web apps in months to come.

Designing with Patterns

We’re lucky to have Bill speaking at our upcoming Web App Summit this January in Monterey, CA. He knows a tremendous amount about both creating and disseminating patterns, and his full-day tutorial with David Malouf contains an in-depth discussion about them.

Here’s a snippet from the article about how patterns play a dual role for teams:

“Patterns really act both as a design vocabulary and as a way to capture emergent best practices within the context of a specific design problem. With the recent advent of AJAX and the resurgence of Flash within the page, there are a number of new (and old) idioms that are now appearing on the web. As these idioms emerge, it’s handy to have a common terminology across Yahoo! for referring to them.”

Joost points out that single-screen interfaces have a big advantage over page-based approaches because they allow users to work in their own, non-linear way. He says:

“In a multi-page environment, there are likely to be separate pages for almost every task in the purchasing process, including a search page, a page listing search results, pages displaying detailed information about individual search results, some options pages, pages showing pricing and availability, and booking pages. It’s difficult to make sense out of such dispersed information. When customers are looking at a page showing details about a particular search result, they can’t see the list of search results, making it difficult to compare and rank different results. When they are looking at a list of results they can’t see the search criteria that produced them, making it difficult to adapt their search criteria and come to grips with all the different offerings.

Customers who need to assess a great many search results must visit and revisit a lot of pages. In doing so, they often lose track of the big picture and waste a lot of time clicking back and forth and waiting for the server to deliver pages. They may become disenchanted with an online travel site that seems to punish them for not knowing exactly what they want.”

Although Joost doesn’t mention them specifically, an excellent example of a single-screen travel interface that realizes much of what he’s talking about is Kayak.com, who have continually iterated their interface over time with incredible results. They combine a single-screen with various filter mechanisms to make finding the right flight really easy. Here’s a screenshot:

To get the real experience of using Kayak’s single-screen interface, simply perform a search from their homepage. The results are a great use of what Joost calls “spatial adjacency”, meaning that multiple items (that used to be on separate pages) are now in adjacent positions on the screen.

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”

Other People Have the Itch, Too

What happens next is the same: after you scratch your own itch someone realizes that others have the itch, too. It might be the developer who notices, or another user. Mike McDerment, who co-founded Freshbooks, a web-based accounting application, describes this:

“(We) founded the company in January 2003. We were doing web design and development projects for various clients. We built FreshBooks for ourselves and very quickly realized that other businesses needed a painless billing solution. We put our heads down and got to work.”

Eating Your Own Dogfood

After you realize that others have the same problem, the next step isn’t to start building for all of those other people and assume you know everything. No, it’s to continue to design for yourself, and then use the product for an extended period of time. Play with it, push it, pull it, make sure that the features there are the right ones, not the nice-to-haves.

Christina Wodtke (who spoke at our User Interface 9 Conference), is working on a new web app: Public Square. She’s testing it out in a small way before releasing it as a service, using it to run one of our favorite sites, the online magazine Boxes and Arrows. She’s effectively killing two birds with one stone…using it herself as well as testing it with others to get real feedback.

Increased Passion for the Work

This users-as-developers cycle may be more virtuous than others. Dan Cederholm, who co-built a wine-sharing site called Corkd, describes how much more passionate he is when working on his own project.

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people. Cork’d has been the complete opposite situation, where we’ve been able to launch a product that would be considered “done” under most circumstances and then react to member feedback using the same attention to detail that went into the initial construction.”

A New Model

At first, it can be quaint to say that building for yourself is a nice perk of your situation. Increasingly, however, starting with eBay and now with firms like these four (and countless others as well), this new model is becoming the de facto way to develop, a critical part of success. If you compare a piece of software created by its users vs. one that’s not, it’s pretty easy to tell the difference. The designers understand the problem better, they’ve worked through most of the issues, and they’re more passionate about it after all is said and done.

Have you ever noticed that many successful web apps seem to change a lot? The designs are always being retooled, changed, improved, upgraded, tweaked?

This is a trend we’re seeing more and more of. Many teams are changing their development process to speed up iterations. Instead of taking months to roll out a new release, they’re breaking it down into smaller parts and releasing them more often. This helps to reduces risk, the smaller the change the smaller the risk and the easier it is to figure out what is working and what isn’t working. Taken to the extreme it would be science: test one isolated variable at a time and iterate accordingly.

One of our clients recently told us, “the faster we iterate, the faster we learn”. In his view, the quicker they release iterations, the quicker they can improve on them. They call this on-the-job-training, referring to the app as being tested by the actual users while they’re using it, as opposed to traditional pre-release testing.

So how fast can app iterations get? Well, teams are all over the map. Another team we know takes about 4 months to make any change to their web app, even the smallest text tweak. If they want to change a navigation button to read different, it takes 4 months. The levels of corporate hierarchy and business rules simply take that long. Interestingly, the product inventory on their site is updated daily, by a completely different development team! They have fully separated their application framework from the products they’re showing in it.

Most teams are faster, though. Mike Davidson, who founded Newsvine, a social news app, recently wondered if two week iterations were fast or slow. Apparently, for some teams it is dreadfully slow, as they update as fast as they can.

I spoke with a developer of QVC.com at the UI Conference who said they often update their site several times a day. Their promotions practically demand it. One promotion might run out in twelve hours and they have to get it on the site and taking orders as fast as possible. He said they also do extensive A/B testing to see what sorts of promotions work and what ones don’t. But they bypass that slower testing method when they need to get a promotion up quickly.

Iteration for iteration’s sake is probably a bad strategy. But many teams are moving to fast iterations to both learn things faster and sometimes simply because their business rules demand it.

So, how fast are your iterations?

Note: This post grew into an article: The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site

Download a Free Chapter of The Designer’s Guide to Web Applications here.

We’re really excited about this report. One of our most popular conference speakers, Hagan Rivers (who is giving a full-day tutorial at the Web App Summit in Monterey this January) has distilled some of her vast knowledge of web applications into this easy-to-read report. Some of the topics she covers are:

• How to build your application’s structure diagram. Hagan will explain how to use structure diagrams as shorthand for visualizing your designs. Structure diagrams help you communicate your application’s structure with your team members and to help everyone focus on the key parts of the design.
• How to identify the two basic forms of application structure: Hubs and Interviews. The two most common structures found in web apps, Hubs and Interviews are essential components in your toolkit. You’ll get a comprehensive introduction to these two components, with several examples showing you when to use each type of structure.
• Which design elements to use. Hagan will show you where and when to use tabs, menus, breadcrumbs, links, and titles in your application. She’ll go over the strengths and drawbacks of each element.
• How to build your application’s Command Architecture. When you design the organization of an application, you’re building a command architecture, a hierarchy of hubs and interviews reflecting each command in your application. Hagan will show you how to build your architecture, step-by-step.

If you’re just getting into web apps or are working on improving the design of an existing one, Hagan’s report will prove invaluable. And don’t forget to check out the free chapter

• You enable two-way communication
  A web application is, above all, enables two-way communication with users. It’s a conversation between a user (or users) and the web app, with the web app presenting a series of interaction possibilities and the user interacting with them. This is in contrast to a one-way, read-only experience where the user sits passively by simply reading information. In web apps, reading is only half the conversation. Listening to, processing, and saving information is the other half.
• You have HTML forms
  Some folks equate an HTML form element with web applications. If users are submitting or changing information with an HTML form, then they’re using a web app. This is similar to a two-way conversation: if you have a form then users can talk back to you. If they’re simply browsing around without submitting anything, it’s probably more of a site than an application.
• You think in screens instead of pages
  Like desktop applications, web applications are built out of screens instead of pages. Screens are different from pages in that they serve to handle some sort of transaction, generally following interaction design principles (e.g. show system status and provide feedback) in addition to graphic design principles. This, of course, didn’t stop people from building apps out of pages, but the swiftness with which we’re moving to AJAXified apps suggests just how inelegant the page model is for interaction.
• You have user accounts
  One of the traits of web applications is that they have user accounts. This is necessary to save personal information such as order history, preferences, and bookmarks as well as provide authentication for accessing personal data. Online banking, blogging tools, and your favorite photo sharing site would be impossible without them.
• Your interface is your product
  Most web sites exist to do one of two things: advertise something or display unique content. In these cases the web site itself is not the product: the product is only revealed in some way through the interface. In web applications, on the other hand, the interface is the product. The interface is the customer-facing artifact through which users get value and communicate with the organization. Some companies, such as Amazon and Netflix, rely solely on the application to deal with customers. Each of these companies wouldn’t exist without their web application doing the work.

(If you’re thinking about attending our Web App Summit in Monterey, California this January, and are having trouble convincing someone that you’re working on a bona-fide web application, this list is for you!)

http://www.flickr.com/groups/ui11/

Feel free to join the group. The tag we’re using is “UI11″.

Here’s a snapshot we’ve already uploaded to the group. It’s from Jared’s keynote, which we’re listening to now. This is a shot of me and Colin Price, the Manager of Media and Technology at Harvard Health Publications. Colin took this shot with his MacBook Pro’s built-in camera, using one of the image filters in the Photobooth application. I’m jealous…I don’t have a camera on my Mac.

For more pics, check out: UI11 Flickr Group

I’m listening to Bryan and Jeffrey Eisenberg right now (in their session: Creating Persuasion Architecture Online), and Bryan is telling us that, like a kiss, every banner ad is a promise. When you view a banner ad, it is setting expectations about what you should find at the other end…when you click it.

But most banner ads fail to deliver on their promise. Or, rather, most landing pages fail to deliver on the promise made by the banner ads. Most are disconnected with the ad that sent people there, often changing the subject, style, or mood of the ad. This change is detrimental to success. Conversion is all about consistency, consistency, consistency in message. The Eisenberg’s preach this message rather…consistently.

The Eisenbergs (who, as brothers, seem connected at the subconcious level…they finish each other’s sentences with amazing clarity) suggest that the failure of many banner ads isn’t caused solely by the difficulty of the medium, but also because they’re created by different teams or people who don’t create a compelling, seamless experience.

Many banner ads, it seems, aren’t very good lovers. Their promises, for the most part, mean very little.

The usability affinity grid is comprised of 4 levels. Each level builds on the others, moving from business goals to usability goals. Talking about a project in terms of a usability grid helps large or dispersed teams and their stakeholders get on the same page, agreeing on the value provided by a focus on usability in the organization.

Here are the levels, and how they build on each other.

1. Business Goals
   Business goals are the goals that the business needs to reach in order to be successful. These are often very straight-forward, but difficult to achieve. One big goal of many businesses is repeat revenue, getting revenue from folks on a recurring basis. Magazine subscriptions are a great example of recurring revenue occurring on a yearly basis.
2. Issues
   Issues are the problems that arise during daily operation and directly affect business goals. In a call center, for example, the biggest issue is the hold time for incoming calls. As hold time increases, customer satisfaction goes down, and customers become frustrated and angry, making business goals more difficult to attain. We’ve all had the experience of being on hold and having a pseudo-pleasant voice promising us “Your call is important to us”. Argh!
3. Business Objectives
   Business objectives are objectives that, if reached, will solve the outstanding issues of the organization. In the call center example, the obvious business objective is to reduce customer queues. This objective doesn’t lead to revenue directly, but indirectly.
4. Usability Objectives
   If one of your business objectives is to reduce calling queues, then a usability objective might be to enhance the productivity of the call center operators. Designing to support efficiency of use of the call center operators would directly reduce the time it took to handle each call, which would directly address the issue and thus the business goals in the end.

As Sarah and Susan point out, this grid is simply a tool to help design teams within an organization. Some teams already use this sort of reasoning implicitly, without mapping out these levels explicitly. But for those teams who are still struggling with communicating the value of usability, the usability affinity grid can prove invaluable.

‘You don’t always want to write copy that exactly matches the user’s task. It’s a very special skill to write copy that speaks to the user’s task but doesn’t call it out explicitly when you don’t want to. Just imagine those folks who are looking for a hotel room at dirt-cheap prices. You probably wouldn’t write copy that says “Dirt-cheap hotel rooms”, but that might be the idea you want to communicate’.

Gerry’s heavy Irish brogue and great presentation skills makes this much more funny than I can write. But matching the person’s task (and their conception of their task) to the copy on the page is a unique and important skill. Interestingly, as Gerry points out, people do approach tasks in many domains similarly. Many people shop for cars in a similar way, for example. They perform many of the same tasks in the process of purchasing a car, no matter what kind of car they’re looking for or even what country they’re in. Some of these include:

• Choosing a model
• Research financing options
• Research safety/consumer reports ratings
• Exploring pricing options/packages

Though there are many other steps involved, these are big ones that many people buying cars go through. When creating an information architecture, you can be sure that these tasks are going to be important. When matching these tasks to the type of business you have, the actual words in your information architecture needs to reflect the values and ideas of the users you’re writing for, without resorting to saying something like “You’ll be cool with the in-dash iPod player”. Gerry calls this “framing” the web site from a small, core set of tasks, or what he calls the “Long Neck“.

I’m sitting in the Designing Powerful Web Applications with AJAX and Other RIAs session given by David Malouf and Bill Scott. Right now they’re discussing AJAX-friendly application frameworks like DOJO, Ruby on Rails, and Yahoo’s User Interface Library. These guys really know their stuff…I’m finding out how little I know about the latest application technologies.

David is now talking about the importance of talking to developers, really pushing the needs of users and the importance of advocating for users during the design process. He suggests that interface designers, even if they aren’t writing code, could use a high-level overview of the important details of the frameworks their developers are using. This isn’t so that interface designers can give pointers to the developers, this is so that the team can better understand each other’s needs, which leads to better team chemistry and communication. David’s point echoes very closely something that we’ve found at UIE: the design teams that focus on users best are those that communicate most…they’re always talking with each other and learning about each other’s needs.

In general, there’s a tremendous amount of conversation here…I just hope I can remember and share 5% of it!

That’s a tough job, given that the Netflix web site is nearly a pure-play recommendation system, meaning that without the recommendations feature the site is only a shell of its former self. The recommendations system is what drives Netflix. Roughly 2/3 of all rented movies there come from recommendations.

As far as building a better system, Reed Hastings, Netflix’s CEO, admits that they’ve hit a wall: “If we knew how to do it, we’d have already done it…And we’re pretty darn good at it right now. We’ve been doing it a long time.”

To bootstrap the contest Netflix is making a huge part of its ratings database public so contestants can deal with real data and results can be judged objectively. Though they’ve taken major precautions with their data, this is a daring move after the recent AOL debacle, wherein AOL made part of their search queries database public and even casual browsers could easily figure out who the queries belonged to. That shouldn’t happen in this case, though, and even if it did the data should not be as sensitive as AOL’s.

I think this is a really good move by Netflix. They’ll get a little press out of it as well as a better recommendation system and a better service, benefitting them two-fold. I wonder what other, similar ways companies could do something like this, open-sourcing innovation?

This could have broad effects over many industries. For many of us, recommendations are how we find out about and decide to try something new (not just movies, music, and books). We might get a restaurant recommendation from a friend, or a digital camera recommendation from a geeky cousin. We do this to save ourselves time…it would be impossible to do good research on all the items we’re interested in. Recommendations are a shortcut to good information, and most of the time are well-considered. I’m really interested in them not just because I’m speaking about them at UI11, but because I think we’ll start to see a much broader adoption throughout all sorts of web applications.

However, I do wonder how one might go about improving on Netflix’s system. One way would be to have better social data. For example, right now I only have a couple Netflix “friends” in the system, simply because I haven’t bothered to ask the people I know who use it to link up. If those people are who I listen to when it comes to recommendations, then their presence as a friend in the system should definitely improve my recommendations because it better models my current habits. However, this data cannot be part of the database offered by Netflix because it would instantly identify who it belongs to. That’s a paradox of social web sites: there’s an inverse relationship between their ability to recommend things to you and the amount of information you provide. As quality recommendations go up, privacy goes down.

At any rate, Netflix is running the contest for one year. Starting today.

We talked about the design life cycle, what stage certain products and web sites are in, and the similarities between writing and designing. It was really fun for me, as I always learn alot from Luke’s writing.

Here’s a snippet from Part 1 (on Luke’s blog: Functioning Form).

‘In the first stage of the lifecycle the role of visual design is to convey usefulness. I quote you here: “visual design bears the responsibility of communicating the possibilities, limitations, and state of interactions. It tells users what they are seeing, how it works, and why they should care.”

In later stages, the role shifts to usability and then to style. However, there are actually very few product types out there that are only differentiated by style. As you mention, gaming machines by Alienware and Dell may be one type. When new chips come out, both brands’ machines simply get a little bit faster. But Alienware looks sooo cool, that they get the nod when all other things are equal. Clothing is another area where style is a huge differentiator…but there are also attempts at providing better functionality, too. Like Gore-tex.’

Stepping back a bit, however, it is clear that these sites are not only interesting in and of themselves, but they’re also an excellent source of discussion in terms of user experience design. After all, most of what folks like us in the UX industry do is to try to get as much insight as possible into the minds of our users in the hopes of designing systems that they’ll not only use, but be delighted to use. Often we have some idea why people might use software because we can easily relate it to our own lives. Social web applications, and more specifically social networking sites, are often an exception.

That’s one of the differentiators of social web design. It deals with the social lives of the people participating, not just the everyday tasks that anybody can relate to. When we’re studying banking applications, for example, it’s easy to talk about a user transferring money from one account to another because anybody who banks has probably done that at least once or twice. But when we start talking about social issues, like say a couple doing their yearly finances together using a web application, then the context changes completely into something that we might not understand at all. This is because the social lives of this couple, their relationship, is completely unique to them. We don’t understand how they interact, make decisions together, and deal with the aftermath. Designing a system that will delight not just one of them performing a task but both of them performing an activity at the same time is another hurdle altogether.

As a result of this, we’re seeing renewed interest in user research. More and more folks are telling us that they’re dedicating resources to finding out how people use their web applications in the context of their lives, not just in the context of their tasks. This is a great thing! Maybe the social networking sites are useful to us afterall.

We’re just beginning to get started down the road of social web design. The social networking sites are just a beginning, a great starter in a conversation that will be going on for quite some time.

Back then, designers at CNN were tackling some of the common issues we have to consider when making such a move: how many links to include, which links to include, and how long to make each link. One of the decisions the CNN designers made was to put several links in a dropdown menu instead of placing them in the horizontal nav bar. Here is what it looked like:

Well, recently they’ve gotten rid of the dropdown that contained extra links. I had mentioned that these types of flyouts were troublesome to people. Perhaps CNN found the same…here is what the homepage looks like now:

CNN now has a full-width 980 pixel-wide horizontal nav bar, with 19 links! That’s a lot of links! (this is up from 17 links in the April design). They’ve added three links (“analysis”, “offbeat”, and “exchange”) and removed one (“video”).

These slight changes in the design aren’t surprising. Many design teams are moving away from full redesigns and moving toward incremental improvements, evolving a design instead of recreating it. This seems like a good approach for CNN. They have so many people using the site that a day’s worth of usage is probably enough to let them know if something isn’t working. And apparently, their old navigation wasn’t working…

It will be interesting to see how it mutates in the future.

Mike captures what the Eisenbergs call the Conversion Funnel, the funnel of user activity on your web app, in this graphic:

The first key to the conversion funnel is to get real stats on each level. For each level, can you be sure that the number you’re using is accurate? Once you can be sure you’re getting relatively accurate numbers, it’s simply a matter focusing on the leaky levels to improve the situation.

One of the benefits of putting conversion percentages into this funnel diagram is that it gets rid of the more visitors/more revenue tendency. We often see a tendency to focus on getting more folks using an app knowing that revenue will increase as well. That works, but it doesn’t help with efficiency, or making the most out of the users you’ve got. What would be better? Having 1,000 paying users and 1,000 visitors per day or 500 paying users and 10,000 visitors per day? While adding users is desirable, improving efficiency is better.

For in-depth talk on the Conversion Funnel and other ways to improve the success of your web app, check out Bryan and Jeffrey’s full-day presentation at UI11: Creating Persuasion Architecture Online.

“We are reorganizing the content on our site (Customers continually tell us they can’t find things, the context is overwhelming, etc.). I was hoping to use tagging to get an idea of how our customers look for things and then base the structure accordingly. Is this appropriate?”

Yes, this is definitely appropriate. Any insight into how customers look for things is valuable. If you can gain knowledge about how people value your content from the way they create and use tags, then you have a virtual obligation to do so!

As I mentioned in the seminar, tags are simply trigger words. As trigger words, they are triggers to action. When a person sees a trigger word, they act. If you can fill your web site with people’s trigger words, you’ll make them happy because they’ll find the content they were looking for.

In general, we’ve found several ways to discover people’s trigger words:

• Search Engine Queries
  By cataloguing the queries people enter into search engines, you can get a clear idea of the actual words people are looking for. We see it over and over again: when people can’t find their trigger words on a page, they go to search. What do they enter into the search box? Their trigger words!
• Actual Clicks
  By looking at the actual clicks that people make, you can get a good idea of what words trigger them to action. The words might be the words in the actual link, or words nearby.
• Tags
  Tags are a new way to uncover trigger words. Since users are the ones entering tags, we have access to their own vocabulary. This is much more valuable than just a way for users to save things for later (which is the primary reason why people tag). Information architects can gain valuable insights into what language can inform future versions of the web site.

If you haven’t noticed, we’re excited by tags. One of the reasons why is that they are a source for ever-valuable trigger words.

Several of the questions dealt with a common concern: tags are messy.

Tag are messy because there are no rules about how to create or use them. This makes it possible to do almost anything with tags, including, but not limited to:

• Misspell tags ( new-york-sity )
• Use different tags for similar things ( new-york, newyork, newyorkcity )
• Use slang ( bigApple )
• Use context-specific tags ( my-hometown )

The concern with tags like these is that meaning is lost when people tag this way. For example, what if someone is looking for all the information on New York City? Wouldn’t they have to look under each of these tags (and probably many more) in order to find all the useful stuff?

Ironically, what makes tags messy also makes them powerful. The flexibility of tagging systems to support a set of tags for each individual is powerful because people can adapt tags to their needs as they see fit. They can use them however they want to. If they want to tag something using slang, they can. If they want to use different tags over time, they can. If they want to use a cryptic language that nobody understands, they can.

Much of the concern about messiness, however, is about the social use of tags. How can I use someone else’s messy tags? This is an interesting question, but if we were to get away from messiness we might have to start instituting rules about tagging. One rule might be: “if you’re tagging something about New York City, use the tag NYC”.

So there’s a tradeoff between the flexibility of tags and their social use. The more flexible they are for users, the less valuable they are to others. The less flexible they are for users, the more valuable they are to others.

But instituting rules for tagging and making them more valuable to others might not be the right way to handle this because most tags are created with a personal use in mind. How can I tag this thing so it is valuable to me? As we’ve seen, people find tags valuable in different ways. This diversity requires flexibility.

If tagging systems weren’t so flexible, they might be less messy. But we might lose their benefits, too.

Yahoo seems to be suggesting that instead of going to the homepage to search I should bypass it and search from my browser instead.

My guess is that this is an attempt to take market share away from Google, whose engine is the default search option on Firefox, the browser I was using. If Yahoo can get Firefox users to switch from Google to their search engine, they’ll see a growth in advertising revenue. As you have probably heard, advertising revenue from search is a huge market, coveted by all and solely responsible for Google’s tremendous growth. A while ago I wrote about how Microsoft and Google understand the Power of the Default. Add Yahoo to that list.

But I wonder: Are there any downsides to this? Does it hurt Yahoo at all if I don’t go to the homepage when searching? From a purely functional standpoint, I don’t think it does. People will still get the value out of the search function that they got before, assuming the results are relevant. Branding-wise, however, there might be downsides since Yahoo relies on services other than search (unlike Google). Each time someone goes to the Yahoo homepage to search they see what are essentially advertisements for services. Does this advertising have a positive effect over the long term? Will someone be more likely to return to Yahoo after having seen one of those services, even if they were there for a different purpose?

In design there is always a tension between discovery and task. Designers want to help people complete their task, but also want to introduce new things along the way. How else would people find out about new, exciting things if it weren’t for some vehicle of discovery?

One option would be to extend what we at UIE call seducible moments to the search results page. Seducible moments are moments when users can be persuaded into taking some new or additional action. Usually this moment comes right after they have completed their task.

However, nearly all of the content on Google and Yahoo’s results pages is either search results or 3rd party advertising. What if they took advantage of the seducible moments on those pages and advertised their additional services there?

Imagine if, somewhere on the search results page, Yahoo’s designers presented this message: “Looking for secure, web-based email? Try Yahoo Mail today. It’s free.” Now, it might be that users ignore everything on the results page and the seducible moment happens when the user reaches the site the results suggest. If that’s the case, however, it is too late for Yahoo to do much of anything.

If that’s not the case and people are open to discovery on the search results page as they seem to be with 3rd party advertising (testing could verify this), then Yahoo has room to explore. Indeed, Yahoo would need to explore in this space if a significant number of people come from browser search. When users search by way of the browser the results page becomes the only place that Yahoo can show off their services. In an increasingly search-driven world where people can search from anywhere, the results page becomes even more important than before.

The new feature, a search box located in the top right hand corner of the browser window, is very similar to the ones currently included on other existing browsers. Here is what the feature looks like in my browser of choice, Firefox:

The feature allows users to type in a search query without first going to a search engine’s homepage. In this example, the search engine that will be used for the search is Google, which is also the default in Firefox. However, using the tiny dropdown arrow I can select from other search engines, including Yahoo and Amazon’s A9. In Internet Explorer 7, Microsoft will be using their own search engine, MSN Search, as the default. Microsoft does not have a search box in its current browser: IE 6.

There’s the rub. Even though the current crop of browsers with search boxes default to Google, Google doesn’t want Microsoft to be able to default to their own search engine. And for good reason, as this would dramatically affect users who make millions of search queries every day.

The Power of the Default

By filing this complaint, Google is acknowledging the Power of the Default. The Power of the Default is the observation that most users never change the default settings in software. In this case, it means that most users who upgrade to IE 7 will simply use the MSN search engine because it is the default choice.

In order to give them choice, Google says, users should be asked what search engine they want to use during the installation or upgrade of the browser. That way, users would clearly see that Google (and presumably other engines) are options in addition to MSN. In order to stay consistent with their argument, Google has gone so far as to say that they support this even for browsers on which they are already the default. This is a clear indication that Google is scared of the Power of the Default.

More generally, the Power of the Default is the primary way that Microsoft continues to enjoy a huge market share in the overall computer world. They were incredibly clever to write contracts with computer manufacturers that made Windows the default operating system on new machines. (just try to buy a Dell laptop without Windows) Because of this default, a large majority of people never realize that there are other options they could choose from.

And now Microsoft hopes to do the same with search. When IE 7 is released, it will be interesting to see if Google can overcome the Power of the Default.

The first method, the tried-and-true method of focus groups, has alarming points of failure. It turns out that people don’t necessarily answer truthfully when asked something. Or more accurately, they can’t be objective about their own opinions, or even why they hold such opinions. We’ve seen people come into user tests tell us they always read privacy policies and then go right ahead and not read any. We’ve learned over time that they’re not really lying to us, but that we should suspend our belief until after we’ve watched them for a while.

The second method, the new method taking hold on the Web, is much more interesting because we learn things about people that they can’t tell us themselves. By observing people we know they hardly ever read privacy policies, how-to instructions, or anything not written in the equivalent of 80 point types in all caps with seven exclamation points. Of course, people do read, but very differently than how they might tell us they do.

New technologies are enabling us to learn more than we’ve ever know about how people behave online. We can aggregate inbound links, number of times emailed, reactions on blogs, number of times visited and revisited, as well as a whole assortment of other metrics, depending on what statistics package we have installed and what we can cobble together on our own.

On UIE.com, for example, I can tell you that the most emailed article is 5-Second Tests: Measuring Your Site’s Content Pages. It has been emailed 40% more than the 2nd most-emailed one: What Makes a Design Seem ‘Intuitive’?.

Interestingly, the most visited article on UIE.com is not the one about about 5-second tests, nor is it the one about making designs intuitive. The most visited article is one that is emailed only half as much. It is the Branding and Usability article.

Why the discrepancy? Why aren’t the most emailed articles the most visited as well?

Surely, the answer is an evil multi-variable math problem. We could look at the inbound links of the articles to see if those links give off the right scent and so set accurate expectations about where the links goes. We could see if there are more trigger words in one article vs. another. We could see what topics are popular on the Web at the moment and see if that has any affect. And there are countless other things we could look at, shake our heads over, and otherwise ponder.

Recently I’ve been watching the new Most Popular page on the New York Times web site. On that page you’ll see this:

Here are two lists. One is most emailed, and one is most blogged about (most linked-to). The lists are rarely the same, and usually only have a couple of articles that overlap. As you can see, when I grabbed this screenshot there were zero overlaps. How can that be?

The answer might have to do with accounts. You have to be signed into a NYTimes account in order to email an article. On the other hand, anyone can link to an article. Or the answer might be technical. When you link to an article, you probably link to whatever URL is in your browser, but most articles have a myriad of different URLs because of the variables attached at the end of them. The article that I read is going to have my account identifier attached to its URL, while an article that someone else reads will have their account identifier attached to its URL. Different URLs… all for the same article. The answer might also have to do with the patterns in how people read. People will email things instantly, but probably mull things over a bit before they link to something. After all, they might write up a short post about the article they’re linking to, and that takes time.

These three reasons may or may not have any affect on how the Times comes up with their most popular rankings. I don’t know, but I do know that there are many other reasons in addition to these that could complicate this matter even further. The end result is that there are too many variables to sift through easily, and so any analysis of the real value of content would probably come with a large set of disclaimers, such as “this was affected by the recent White House dustup” or “this was affected because it wasn’t posted until later in the day”.

The Most Popular page fascinates me because of what it might be saying about how people value content. But beyond an interesting novelty it’s hard to know what the lists on the page actually mean, given the large number of things that affect how people behave on the Web…and the increasing complexity with measuring those things.

Kind of makes me feel like just asking someone instead.

Interestingly, the designers didn’t change (or haven’t yet changed) the interior pages of the site, driving consistency-minded designers nuts everywhere. Fortunately, however, this gives us the opportunity to look closely at the decisions they made, and to highlight several issues involved in making such a change.

Here’s what their homepage looked like this recently:

And here’s what an interior page looked like:

As you can see, the layout has changed dramatically. The content has been shifted left, where navigation used to be. The navigation is now in a thin blue bar across the top of the page. This has the positive effect of moving the visual weight away from the navigation and toward the actual story. When the navigation is on the left, our eyes are instinctly drawn to it, even when we already know what it is. This distraction, however small, is less noticable in the new horizontal design.

To get this change, the designers didn’t simply put the left-hand nav buttons end-to-end across the top of the page. No, they had to make several design choices. Most of these choices were influenced by the width of the page and the number of links they were working with.

1. Link length shrinks
   One of the first things to change when navigation goes horizontal is the length of links. In the CNN design, the designers shortened several links. “Business at CNN Money” became “Business”. “Sports as SI.com” became “Sports”. “Autos with Edmunds.com” became “Autos”. And “Special Reports” became simply “Specials”.

   Our research here at UIE has shown that the longer the link, the better it works. In this case, however, it doesn’t seem like much was lost when the links were cut down. Was “at CNN Money” really adding any relevant information to the “Business” link? Probably not much. Even so, reducing the “Special Reports” link to just “Specials” seems to have lost something.

   Navigation bars, however, are a special case of links. In general, we’ve seen short, one-word navigation links work at the top navigation level on sites when the subsections are relatively distinct. However, as you delve deeper into the site, links tend to work better when they are longer because they need to contain more information that differentiates them from their siblings. For instance, “Sports” and “Business” are two relatively distinct categories, so creating top-level navigation links with just those words might be appropriate. But when on the “Business” subsite, everything has to do with business, so the links need to clearly differentiate what those differences are. The more words there are in the links, the easier it is to do that.

2. # of navigation choices changes
   In the vertical nav configuration on the CNN subpages, there are 17 navigation choices. In the horizontal nav configuration on the homepage there are only 12. The designers have cut down on the choices in order to save space. There would not have been enough room to put all 17 on the horizontal nav bar at the same page width.

   In order to keep the same navigation choices as before, the designers chose to utilize a dropdown box to hold the remaining links. This is a common method that designers use when they don’t want to place all the links on the page at the same time. However, our research has shown again and again that dropdowns and flyouts don’t work very well. Our classic article Users Decide First, Move Second talks about this in more depth.

   As a result, I would bet dollars to doughnuts that those links in the dropdown have fewer people clicking on them than they did when they were in the vertical nav bar. The reason is simple: people have to work to see them now.

3. Prioritization of choices
   The designers at CNN didn’t simply take the last five links and put them into the dropdown. If they had done so, they would have chosen “Travel”, “Education”, “Special Reports”, “Videos”, and “Autos”. Instead, they chose “Law”, “Science & Space”, “Travel”, “Education”, and “Videos”. Obviously, the designers thought that “Autos” was more important than “Law” and “Special Reports” was more important than “Science & Space”. They made an explicit decision to prioritize some over others.

   This is a common problem issue we see with the move to horizontal navigation. At some point, things have to be cut. Instead of losing value, however, design teams can use this as an opportunity to make a site stronger focusing on what is most important on the site. We’ve seen many design teams try to include everything under the sun into their web site, when in almost all cases the vast majority of visitors come for a small sliver of content.

Those are three obvious design challenges that the team had to face when moving to a horizontal navigation scheme. Most teams deciding this very question will face these and more. Do you have any interesting challenges from a recent move to horizontal navigation? Are you considering such a move?

‘As analysts and representatives of end user requirements, designers are in a perfect place to reposition a “problem” (or market opportunity -if you prefer) to reflect the perspective of the customer. So instead of describing the problem from the standpoint of business goals, designers articulate it by outlining what it means for the end user of a product: the customer.’

(from the post Defining the Problem)

We’re seeing the role of designers evolve toward this as well, moving away from a strict layout-and-build routine to a much deeper integrated level. They’re becoming a support system for users, articulating their concerns and desires back to an organization who may not be aware of what’s going on at ground level. As Luke says, designers are in a great position to be the enabler of communication between an organization and its users.

Also, as you may know, Luke is speaking this year at UI11. We think he’s got a great message to share, and of course we recommend reading his Functioning Form blog.

As we do in many of our studies, we allow our test participants to create their own tasks. This way, they’re much more likely to be shopping for something they’re truly interested in, as opposed to going through the motions for testing purposes. We also give users real money, which makes the incentive to purchase very strong. If someone is truly motivated to purchase, then any problems we uncover that prevent purchasing directly affect the bottom line.

Despite the freedom we give test participants to create their own tasks, we have to be more strict about which sites they visit. The reason is straight-forward: we’re testing the effectiveness of particular sites for a particular purpose. In order to see what works and what doesn’t, we need to watch several people on the same site (especially the site of our client). Otherwise, we wouldn’t have a large enough population to be sure that we weren’t just seeing outlying issues that only affect one or two people.

Amazon.com, however, can make this difficult. When we test sites that sell similar products as Amazon does, (a list that is always growing, as Amazon seems to sell everything nowadays), we always get testers who want to go to Amazon before they go to the site we ask them to go to. “Can I just check out Amazon first?”, they ask. Because we’ve already included Amazon in the testing, we must remind them that we are also interested in learning about other sites, and that they may or may not be asked to visit Amazon later in the test. “OK”, they say reluctantly.

I call this the Amazon Effect. Amazon is so strongly rooted in people’s minds that it overrides their desire to try out other sites, even if it’s during a test! And it was funny at first, when we would have to say things like “well, we may or may not ask you to test Amazon today, but either way, you can go there on your own after the test”. This always seems to make folks feel better.

But our biggest insight into this behavior came when we started questioning why Amazon was so powerful. Why do people have such an urge to visit Amazon before they go anywhere else? This wasn’t happening with other sites, only Amazon. What makes Amazon so special?

One of our first hunches was that people were so strongly leaning toward Amazon because they already had accounts there. It turns out that this isn’t the reason, though. Even though their credit card information is stored on Amazon’s servers, the few moments they’ll save not having to type it in again isn’t the reason why they want to go to there. It’s not the prices, either. People expect low prices at Amazon, but they don’t seem to think that Amazon has the lowest prices.

In fact, the testers don’t necessarily want to purchase at Amazon. They don’t say “I would rather shop for this on Amazon”. What they say is, “Can I go to Amazon first“. This subtle difference in wording turned out to be the clue to what drives them there.

The real cause of the Amazon Effect is research. Amazon has become the Consumer Reports of the Web. The primary reason people go to Amazon is to do product research. They trust what they find there and it heavily influences their purchasing decision. Some people we’ve tested claim that they go to Amazon and read the reviews there before every purchase they make. They want to be sure that what they’re buying has been positively reviewed.

Another interesting behavior we’ve seen is that some people only read the negative reviews, as if they’re looking for a deal-breaker review that just makes it impossible to purchase. We’ve heard comments like “I know what the positive reviews will say, but I don’t know what the negatives ones will say”.

The Amazon Effect is very strong, and we’re continually faced with it. However, it doesn’t seem to affect the usability of the site, as we find just as many problems on Amazon as on other sites (especially with third party sellers). But even with its own usability problems, Amazon has an effect unlike any other site we’ve tested.

Here are my slides (added a few since the talk). Web 2.0 – Leveraging the Network (pdf)

Major talking points

(the slides contain a little history and examples/supporting information for each)

• The home page is no longer the most important page on your site.
• The information architecture that people use to find your content is, increasingly, not yours.
• Each feature added to an application is more to think about – for everyone.
• Folksonomies are a way for users to map their own, familiar vocabulary to your alien one.
• Words are the currency of the Web. Spend the most time on your words.
• Seducible moments are those increasingly rare moments when you can talk to your users in an appropriate context.
• Recommendation systems are a forced move.
• Users want control.
• Users appreciate tools that help them make their own well-informed decisions.
• The best software models human behavior.
• Links model how users value content, and are only the start…
• Sometimes it is easier to design for yourself than others.
• There is always an opportunity for a better interface to data.
• All things being equal, faster interfaces allow for more innovation.
• Most people are willing to trade their personal information for good service.
• As choices grow, so does the importance of learnability.
• Redesigns are dead.
• Network effects are rare, and killer.
• Network effects work in the opposite way for teams building software.
• Personal value precedes network value
• People rarely do things for the “good of the network”
• Del.icio.us, though providing very cool tagging features, is mostly about a single person remembering items for later.
• “The accretion of tiny marvels can numb us to the arrival of the stupendous”

One way to help alleviate our frustration at this moment is to look to other designers for the answer. If you’re working on a web site, for example, you might go look at your competitors and see what they’re up to. How did they solve it? Does their method seem better or worse than the one you’re considering? Would it be wise to simply assume that they figured out the best way to solve it and do something similar?

In research this is akin to a “product review”, and if done cautiously, can save a lot of time and frustration. For example, we’ve done in-depth competitive analyses on top e-commerce web sites where we look at how competing sites solved similar problems: like helping users find that perfect laptop, for example. When we present our findings, we make sure that our road to recommendations was based on how the sites actually performed, not on what site had what cool feature.

Unfortunately, it’s all too easy to take a different route at the moment of innovation. Many times, when the answer is not clear and doing research seems daunting, we see “feature grabbing”, a technique where you simply grab features that others have used because they seem like a good idea.

But it’s not always a good idea to feature grab. First of all, you can’t be sure that the feature even works. Just because a competitor has a feature doesn’t mean you should have it too. We’ve seen many cases where features that were copied directly failed to work, and it wasn’t because they weren’t copied faithfully, it was because they weren’t addressing the actual problem.

This idea was captured perfectly in an interview of Dean Kamen I read recently in Make magazine. (subscription required ;( ). Dean is one of the greatest inventors of our time and his company, Deka, is right up the street in Manchester, NH. You may have heard of their much-hyped Segway Human Transporter, their dialysis machine, or their current incarnation of the Stirling engine.

In the following excerpt, Dean talks about how, when they were designing their personal mobility device called the IBOT, they realized that if they did all their research on the existing solution (the wheelchair), then their solution would look and act too much like a wheelchair. This was undesirable because the actual problem was something that a wheelchair doesn’t readily solve. I love his simple and straightforward philosophy on design:

“I try to understand the basic laws of nature. Beyond this, I do very little research as to what the product should be. You would never get the iBOT by doing research on wheelchairs. If you do “product research,” the product that you end up with will be similar to what already exists. For example, if you went out to people who make wheelchairs and said, “I want to make the next great improvement,” they would typically conduct focus groups with people who use wheelchairs. And these wheelchair users, operating within the context of their existing wheelchairs, might ask for things like a new cup holder. They saw a great cup holder in a minivan and realized that their wheelchair didn’t have one. So they ask for a cup holder, or some other incremental improvement. You have to start with basic question: if this person is now missing this amount of functionality, is there some alternative to a wheelchar that is both dramatically better and not prohibited by the laws of physics and the current state of engineering and technology?

“Focusing on the problem in this fundamental way allowed us to understand that wheelchair users need to have the same small footprint on the ground as you and I so they can navigate around areas and obstacles as we do. They need to have their eyes and hands at the same level as a standing person, so they can see over counters and get things down from shelves. They need to be able to get water out of a faucet. And so on. In order to achieve any of these things, we looked a how fully functioning humans do it. They do it by being dynamically stable – by constantly adjusting themselves to maintain balance. Balance is a preprequisite condition to living in a world that is architected by people who walk around balancing themselves. So we decided to forget about wheelchairs and focus on the real problem. The real problem isn’t locomotion – wheels solve that problem fine. The real problem is that these people typically lost their ability to move around while also physically elevating themselves within a small footprint, which requires dynamic stability. Solving this problem would dramatically improve their lives.”

According to this fascinating study done by Marco Iacoboni at the UCLA Ahmanson-Lovelace Brain Mapping Center, whose team used fMRI to record and analyze the brain waves of a small group of people while they watched on Sunday, Disney had the best ad while Sierra Mist came in 2nd.

This study is interesting not just because we all seem fascinated by the Super Bowl commercial phenomenon but because it demonstrates that recording the brain waves of people and analyzing them with an incredibly fast turn-around is possible. Presumably, you could extend this to do studies on people using web sites as well.

But what do the results really say? Was the Disney commercial the most effective, or did it just pique our interest the most? Are those two things the same?

Yes they are, according to Iacoboni, who equates brain activity with success for the ad. He writes:

“The Disney ad elicited strong responses in orbito-frontal cortex and ventral striatum, two brain regions associated with processing of rewards. Also, the Disney ad induced robust responses in mirror neuron areas, indicating identification and empathy. Further, the circuit for cognitive control, encompassing anterior cingulate cortex and dorsolateral prefrontal cortex, was highly active while watching the Disney ad. We consider all these features positive markers of brain responses to the ad.”

Here’s a shot of that technical jargon in action, illustrating neuron activity in the right posterior inferior frontal gyrus – indicating identification and empathy:

Even so, I would want to see how many people actually go to Disney World as a result of watching the commercial. I know it didn’t change my travel plans in the near-term. But I have to wonder, did it effectively imprint happy thoughts in my head, so that the next time I’m in Florida, I just might be more likely to go?

At first blush the Amazon decision is counter-intuitive. It would seem that allowing anybody to say anything about an item would cause it to sell poorly because someone, somewhere, would write one rotten apple review of it and spoil the bunch.

That didn’t happen, though, and the decision Amazon made is very similar to decisions other successful online companies have made recently that are starting to bear fruit. These decisions all have one thing in common: the more tools you provide customers to help them solve their own problems, the more they use them, and the better your site does as a result. Even if you allow for things like negative opinions.

This was an indirect path to success for Amazon. Allowing both sides of the story takes a lot more work than telling only one side. This goes for all types of web sites: being honest is really hard work. If you write, you have to tell both sides of the story even if you lean heavily toward one of them. If you sell, you have to be realistic about what people are buying or they will never come back after they find out you’re lying.

In contrast, the direct path would be to try to control the message for each item being sold on Amazon. That means any potential customer only hears about how great the product is, even if it isn’t really so great. You can still find this type of bias in the publisher’s review that is included on most book pages.

Increasingly, however, people are turning to third parties such as other users to give them unbiased information. It is this indirect, long-term strategy that has paid off tremendously for Amazon. To this day they continue to allow people to write scathing reviews, knowing that as a whole they will be more valuable that way. After all, some items really are terrible, and you’re doing someone a favor if you tell them about it before they lay out their own money to find out.

Indirectness is an underlying secret of the success of the reviews at Amazon, and for all systems used for recommendations. Though they are difficult to create, they give users the tools with which to make better, more informed decisions. Knowing what not to do is nearly as valuable as knowing what to do.

Though we’ve only been at it since July, we feel that blogging has been a very positive experience. So I want to put it out there and see if you have had similar experiences or not. Are you blogging, or thinking about it? If so, do you think that it has been worth it? What has happened as a result?

If you have recently added blogging to your repertoire, we would love to hear about it!

Today Apple has addressed the problem, presumably because I wrote about it. Just kidding, of course, many folks wrote about it, expressing their concern about the feature that was turned on by default. Most (probably not all) of those people will be happy to know that Apple now presents the following screen asking for approval before turning on the MiniStore.

At first glance, this seems a rather trivial occurrence. But it’s actually a big deal. Apple, a notoriously insular company, has changed their software as the direct result of public feedback. The users have won a battle here; their voices were heard.

Kudos to the iTunes developers at Apple for making the change.

If you use iTunes and have upgraded since January 10th, you may have noticed the new feature yourself located at the bottom of your application. The MiniStore feature provides a small version of the Music Store that shows up when you’re browsing music from your own library. If you click on a Van Morrison ditty, the MiniStore feature (below: in light blue) will show links to the latest Van Morrison albums as well as recommendations from the iTunes Music Store.

Even with the amazing good-will that Apple seems to garner from its customers, this has upset many folks who worry that Apple is spying on their behavior without their consent. Boing Boinger Cory Doctorow, former member of the Electronic Frontier Foundation, a non-profit group working to protect digital rights, had this to say:

“I love iTunes because it’s a clean music player. But no amount of clean UI is worth surrendering my privacy for — I wouldn’t buy a stereo that phoned home to Panasonic and told it what I was listening to; I wouldn’t buy a shower radio that delivered my tuning preferences to Blaupunkt. I certainly am not comfortable with Apple shoulder-surfing me while I listen to digital music, particularly if they’re doing so without my meaningful, informed consent and without disclosing what they intend on doing with that data.”

This situation is one in a growing trend that highlights what I’ll call the Paradox of Recommendations. The paradox is that in order to get better service in the form of personalized recommendations, we need to give up more information about ourselves in the process. So as we gain more help in deciding what products and services are right for us, we need to give up some of our privacy as well.

Interestingly, the iTunes case isn’t as much about giving up information as it is about coming clean concerning what the information is being used for. Doctorow explains:

“It’s easy enough to turn off the MiniStore (in the Mac version select “Hide MiniStore” from the Edit menu), and doing so deactivates the spyware behavior. The problem is that when you run the update, Apple effectively opts you in to a data-collection process without informing you that the process is taking place, nor obtaining your consent for it.”

Compare the iTunes bruhaha with another site that collects an amazing amount of personal information: Netflix. Netflix knows a lot about the people who rent movies from them. They know what your interests are, what your movie-watching habits are, your address, the names, interests, and addresses of your friends (who are also on Netflix), not to mention your payment information. The information gathered from iTunes pales in comparison to the nexus of identification that Netflix is gathering. And yet people freely give this information to Netflix in order to get better movie recommendations.

So what can designers creating recommendation systems learn from this? First, openness is key to gaining the trust of users. In the iTunes case, trust is as big an issue as personal information. Most folks were pleased to learn that simply shutting off the MiniStore feature stops the sending of personal information. However, many folks also understood that this feature could potentially lead them to good recommendations for music and weren’t bothered by it at all. Regardless of whether or not this is a concern to you, if Apple had openly notified users that this was going to happen, and given them the choice of whether or not to install the MiniStore, then this whole fiasco would have been prevented.

Second, Netflix proves that people are very willing to part with large amounts of personal information in order to get good recommendations in return. This should give designers hope of creating powerful systems for their users, based on their previous interactions with their service.

But any powerful service should also be tempered by the Paradox of Recommendations: that providing cool features is not just a matter of using personal information in clever ways. It’s also a matter of privacy, and as such, designers need to communicate that usage as clearly as they communicate any resulting benefits.

What MIT doesn’t change is the primary navigation. They have a set of top-level and 2nd-level links that stay the same no matter what day you visit. Only the background image and spotlight change. When I visited recently, the homepage featured a large image of what looks to be the handles and digital interface of a treadmill. This was used to spotlight a program called the Getfit Challenge, a three-month team-oriented fitness challenge for the MIT community. Ordinarily this content wouldn’t be featured on the homepage. But it happened to be the spotlight on the day I visited the site.

When I first saw it, I actually thought I may have typed in the URL incorrectly. After all, I had been to the MIT site before but I didn’t recall seeing anything close to this. My expectations were certainly shaken. However, upon a second look I realized that I was indeed at the correct URL, and one that was more memorable now that I knew what was going on there.

At UIE, we’ve seen a lot of homepages, but we haven’t seen many where designers take this approach. We often talk to design teams who make small changes to the homepage over time, usually promoting their latest offer or information to the most visible part of the page. Some even redesign it completely every once in a while. But changing it every day like this is unique. In most cases consistency is seen as a vital attribute for the look of the homepage. We often hear the phrase “consistent look and feel” to describe this belief.

Not so at MIT. They do what would seem preposterous to the “consistent look and feel” crowd. (I can almost hear marketing and design teams cringe.)

On the other hand, MIT does provide consistent change, showcasing content that folks might not have known about. They have obviously chosen the current knowledge approach instead of the consistent look and feel approach. They trust that new visitors will quickly understand what is going on, making the decision to highlight various programs and the creativity of the community at the expense of visual consistency. And they’ve kept at it for almost 3 years. That tells me that they’re confident it’s working.

So what do you think? Preposterous or ingenious?

Needless to say, my confidence was a bit shaken. Here I was about to do a real transaction with real money, and I get the message that there is a “server error”. In addition to not understanding what went wrong, I’m left with absolutely nothing to do but come back later and retry.

This type of thing doesn’t happen all the much to me, but it does every now and again. And each time I’m left with a choice of whether to continue to use the service or to go elsewhere. It’s a choice that can only be bad for the company in question, and can only do harm to the relationship they worked hard to build with me.

However, I will say that as a web developer I can understand how this might happen. Files don’t always copy over the right way, someone else might have done something silly, or a new plugin fouled things up. A myriad of things might have been the bugaboo.

But on a banking web site? I think I’m once bitten, thrice shy.

One problem with the whole “Web 2.0″ phenomenon, however, is that some people are still uncomfortable with the term. It is easy to see why: people throw around “Web 2.0″ with wild abandon. Some claim it is the cure for your Web 1.0 failings, whatever they may be. Some claim that it is the realization of the full potential of the Web. Unfortunately, the wild abandon has left us with some unecessary confusion.

So, for those folks still wrapping their heads around the whole “Web 2.0 thing”, I’ve created a page called simply:

Introduction to Web 2.0

On this page I’ve included a quick explanation of the term (notice I didn’t say definition), as well as many resources for further exploration. My hope is that somewhere along this spectrum of publications you’ll find one that suits you.

For those interested in the service behind the page I created, it’s called Squidoo, and is a project by none other than Seth Godin, author of the Purple Cow and Permission Marketing books, some of our favorite reads.

The feature is simple. You type in the name of a band/artist that you like, Last.fm spits back related ones, and you learn about bands that you may not have known about. Here is a screenshot:

The designers at Last.fm have recognized that the best way to get people excited about their service is to let them try it out for free. So they’ve placed this handy tool smack-dab in the center of their home page, giving something for nothing in the hopes that folks will enjoy it enough to sign up for the service.

This is a common trend. The amount of time and energy it takes to try out the myriad of services on the Web is increasing. What can you provide for free that is as irresistable as this music recommendation tool?

Here’s a challenge: go to Last.fm and resist the recommendation tool. I dare ya. If you possess any ounce of curiosity you’ll need a whole lot of willpower, too.

We see this all the time. On nearly every one of the projects that we work on, and even the ones that we only hear about, we observe the same thing: the homepage has the highest priority in the design food chain. Much more energy is spent deciding what will go where on the home page than any other page or section of the web site.

The reason is simple. It’s the page with the most page views. Here is a snippet of uie.com’s page views over a few days recently.

The first reaction to a ranked list like this is to pay attention to whatever is ranked at the top. And inevitably, on the Web, that will be the homepage. After all, it’s the default page when someone visits the site. It ends up being an easy target for designers (and everyone else) to focus on.

However, if we push further with these numbers, stretch them out a bit, we actually paint a very different picture of where focus could be paid.

First off is the amazing statistic that the homepage accounts for only 1/10th of the total pageviews. In other words, approximately 90% of the time people spend on our web site is not on the home page! That suggests that there is a sizeable set of pages other than the homepage that fulfill the needs of our users.

And that brings us to The Long Tail. The Long Tail is an economic theory made popular by Chris Anderson, chief editor of Wired Magazine, who pointed out that the Web is enabling a whole class of content to be shared which wasn’t sharable before. Anderson uses physical items like CDs and books as his primary examples, noting that Amazon sells many more unpopular CDs than it does the most popular ones. (simply because there are so much more of them) Interestingly, the theory is equally applicable to those dark and dusty pages on your web site that don’t get much attention relative to the few popular ones.

Here is what The Long Tail of UIE.com looks like:

In this graph, the homepage sits on the left, getting over 4000 hits for the time period. But look to the right, the mass of area filled in with blue. That represents the rest of the pages (I included all the pages that got over 90 hits in the time period – the entire tail is much longer). These are the pages that get the vast majority of attention.

The Long Tail popularizes what mathematicians realized early on when they started researching the Web. That is, there is a pattern to the way that we browse web sites. The pattern is that there will always be a most popular page (usually the homepage) and there will always be a huge collection of pages that garner less individual attention but add up to the vast majority when put together.

Going further, when we separate out the pages in the tail into what areas of the site they are in, we can get an even clearer idea of where people are spending their time.

As you can see, the section of UIE.com that gets the most traffic is our articles section. This is followed by our Brain Sparks blog posts. Even though these sections of the site are made up of multiple pages, they’re mostly template-driven. Therefore, it might make sense to really optimize these templates before moving on to less-visited sections of the site.

We think it’s worth investigating the relationship of where users and designers spend their time. It might make sense for designers to spend most of their time where users spend most of their time. That way, designers will affect the most users possible with any improvements they make.

If you’re a long-time reader of ours, you won’t be surprised by this suggestion. We’ve long sensed that too much effort was spent on homepages. Our research continually shows it. (as do our site stats!) Not coincidentally, Christine and Jared talk about this very topic in our 2006 Roadshow.

Nothing beats a good buzzword, and we’ve found that The Long Tail is an effective way to communicate some of the issues design teams face. (In addition, it makes a great visual and opens up a slew of opportunities for making puns)

So that’s a little of what we’ve learned from analyzing our own tail. What does your Long Tail tell you?

Here’s Amazon‘s account login:

As you can see, the messaging says that ordering from Amazon is quick and easy. Placing this message here is a good idea. (unless it’s not true, of course) Then we see something rather unique, a set of radio buttons that allows the user to choose whether they are a new customer or a returning one. If they are a new customer, then they must sign up for an account. If they are returning, they need to enter their password.

We have seen users have difficulty with this particular feature in the past for several reasons. One is when registered users enter their password but neglect to click the radio buttons. The other is when new customers, after entering an email address, enter their password too, thinking that they’re going to create an account with that password. (despite the helpful text that says you create your password later)

Here’s the redesigned Circuit City web site:

The Circuit City design starts out by asking users if they are registered, and if so they can sign in to speed through checkout. Like Amazon, the designers at Circuit City are touting the benefits of signing in, which we’ve seen as critical to getting users further along the Customer Sieve.

But, unlike Amazon’s radio buttons, the choice isn’t a clear this or that. In the Circuit City design, both registered and non-registered users need to complete the questions on this page. The only difference is that those users who are registered can click the input button labeled “sign in” first, and then they’ll be brought back to this page to continue filling it out. In effect, there is no choice between either signing in or creating an account. It doesn’t state that explicitly, however.

Contrast that to the Best Buy checkout:

The designers at Bestbuy chose a different approach. They make it explicit that users can checkout without signing up for an account. In our testing we’ve seen users really appreciate this option. In addition, users can create an account during the checkout process to speed future purchases. You can’t tell if that’s possible on the Circuit City site. In general, we’ve seen approaches that make these details like this as clear as possible work better than those that don’t.

And then there’s Yahoo, who seem to desperately want users to create a Yahoo ID:

Like the others, Yahoo is providing a choice and touting the benefits of sign up: “It makes ordering easier and will provide access to your new Business Edition service”. Unlike Best Buy, however, sign-up is not optional.

I’m interested in how this plays with users. Do they want to sign up for a new business service, or do they want to simply check out this one time? While we haven’t tested this Yahoo feature specifically, our experience testing checkouts has suggested that people often shy away from “fringe benefits” like this, especially if those benefits are not explained fully. (and much moreso if they have a choice not to)

The choice that Yahoo does provide is rendered in text, instead of input buttons or radio buttons like on Circuit City and Amazon. They do it with a link called “Create one now” and a sign-in box to the right. This is similar to Amazon and Best Buy, who include the text boxes directly on the page. Circuit City, on the other hand, takes users to another screen to enter the sign-in information.

So how do you handle sign-in? As you can see, there are as many different ways to handle sign-in as there are web sites. I stuck to e-commerce sites for these examples, but the basic problem is the same for all sites: articulate the choices that users have, explain the benefits or drawbacks, and guide them through making their decision. Do your design projects take you in similar directions as these four sites, or completely different ones?

A watershed moment is happening with online maps as we speak.

First is was Housingmaps, created by Paul Rademacher, an application so obviously cool and useful that is started a revolution in mapping. Housingmaps was built using Ajax, the technology du jour, and after one look at Housingmaps you no longer needed to know why the Google Maps service is useful. The only problem is determining if it is useful in your projects.

As a result of the Google Maps watershed moment, we now have maps that can help us find schools, view subway stops in Paris, and locate cheap gas. (check out Google Maps mania for many, many more)

Now there is a watershed moment for Yahoo Maps beta, released last week to great fanfare because it sports an even smoother interface than Google Maps. It’s not based on Ajax, though. It’s based on Flash, the much maligned tool that spawned the evil Flash intros that are fading all too slowly away.

Though the new Yahoo Maps is nice, and serves to bolster Flash’s reputation, the real watershed moment comes from a developer, Justin Everett-Church, who has manipulated the Yahoo Maps API to produce something pretty amazing: a map that looks any way you want it to. In his post on the topic, Justin shows off two very different maps, both using the same underlying technology. (note that you’ll need Flash 8 to view it correctly)

Here’s a screenshot of one, a radar map:

The map behind this radar screen is the same map as on the Yahoo Maps site, it only looks different. Justin has taken the Yahoo Maps API and innovated beyond it by adding his own visual filters. While this is only a proof of concept, with further development you could plot coordinates, zoom in, and give folks some of the more advanced functionality that the other mapping applications have.

I think this is another watershed moment in the online mapping area. After seeing Justin’s work, don’t you just want to just go out and make one yourself?

As you may or may not know, we develop the UIE web sites with the goal of developing equally for all major web browsers: IE, Firefox, Safari, and Opera.

On this note, I recently checked up on the browser statistics for the Brain Sparks blog. The result was surprising:

As you can see, Firefox is the browser of choice among the Brain Sparks crowd. This is interesting because Microsoft’s Internet Explorer is so well-entrenched in the overall web picture, with estimates of its share running from 55 to 95%, according to Chuck Upsdell’s Browser News, a long running yardstick of the industry.

For those designers out there who are struggling with whether or not to develop for IE-only (a strategy for many banking sites, it seems), let this be another data point on your radar. Not only is Firefox growing (albeit not as fast as they were), in some circles (like ours) it is the most-used browser.

Thankfully, Firefox is not a closed platform, nor do they try to be. As a result, I believe the growth of Firefox and other browsers is a great step forward in how we design, because it helps make the “IE-only?” question meaningless. And that is a good thing.

One technique that we’re already finding valuable is folksonomies, a bottoms-up, user-driven way to bolster a web site’s information architecture. Folksonomies gained popularity after sites like Flickr and Del.icio.us started using them. They work by aggregating the tags that users attach to items in the system. In Flickr, users tag photos. In Del.icio.us, users tag bookmarked web pages. By aggregating the tags, the system can illuminate trends that aren’t apparent otherwise.

For example, by watching the usage of the tag “ajax” in Del.icio.us, we can find out if it is catching on (increasing in use), or if it is dropping out of favor (decreasing in use). This allows us here at UIE, when we’re doing our research into design topics, to feel more confident if we are talking about something that may be new to people. If we’re seeing a lot of other people using the term confidently, we can be sure that we’re not entirely out in left field, clinging to an idea that isn’t working. In this way Del.icio.us has been very valuable for us, and it’s all because of the folksonomy.

One of the problems with folksonomies is that it is hard to tell how they might help on different kinds of sites. Sure, they really make Del.icio.us worth using, but what about a retail site or a educational site? Can they be applied there with equal success?

Two recent articles address this issue by describing real-world uses of folksonomies:

• Tom Coates, who works at the BBC, writes a nice article on How to Build Bubble-up Folksonomies on his personal blog Plasticbag.
• Businessweek published Tagging: Keeping Tabs On The Net in which we learn how one CEO is using Del.icio.us to find out how people are reacting to brands that he helps produce.

Stories like these two are not just interesting stories to tell around the watercooler. They’re also useful in demonstrating to stakeholders how folksonomies aren’t just a new way to build an ad-hoc categorization scheme, but are also very good at tracking trends and possibly providing recommendations.

That’s really what trend-watching is all about: observing what is happening, and then making informed decisions about what people will find valuable in the future. Or, put another way, preparing for change.

Here’s the article: New Approach From Gap to Cut Down on Clicks (Note: due to a very recent change, this article is behind a paid firewall. It costs $3.95 to view…however we have cited the most interesting bits below.)

But the story got even more interesting as we read that the new site boasts tons of features that “other retailers will quickly try to figure out how to copy”, according to Forrester analyst Carrie Johnson. As if that weren’t enough, Ms. Johnson then pointed out that Gap.com had largely solved what she called the “too many clicks” problem.

Needless to say, we had to take a look at the site for ourselves. If you’ve read Testing the Three-Click Rule, you’ll know that our research suggests that when people complain about the number of clicks they’re making, it’s often a symptom of a different problem, and that problem is that they’re failing to find what they’re looking for.

So we headed on over to Gap.com and took a look around. What did we find? We found the claim that people had to make fewer clicks than before is largely misleading. In fact, users have to make just as many clicks as before. The real difference with the design is that instead of reloading the existing page or loading new ones when a user clicks, a click might launch a popup instead. Here’s an example of one:

This popup, used for selecting the size and color of jeans, is interesting for several reasons:

1. You can select color and sizes by clicking on a size box, without a reload.
2. Available sizes are highlighted and clickable. Unavailable sizes are greyed out and unclickable.
3. The enlarged product photo shows decent detail.
4. You can view a size chart and more product details if you need to.

In short, the popup contains enough information to select an item, customize it, and add it to the cart, bypassing the effort of visiting each product page in turn and doing it there. Presumably, this is why the redesign is so exciting, even though the Times article instead points to the number of clicks as the issue being resolved. (Lots of people blame frustration on clicks, but they’re often just innocent bystanders).

The design has some really neat features, though. When you hover over a waist size, for example, all the pant lengths that are out of stock for that waist size get greyed out. This is similar to one of our favorite sites: LLBean.com, who have done live inventory updating for some time now. They use dropdowns instead of hover boxes, however.

These sophisticated inventory features could explain the slowness of the site, although that could also be the result of a myriad of other things including a pent-up demand resulting from the 2 weeks offline or the increased traffic brought over by the Times article. Even still, if the features work as well as advertised the download time of the pages won’t matter to the site’s bottom line, as we’ve found that download time is not as important as you might think.

Additionally, a quote from a Gap executive concerning the project was really interesting:

“Toby Lenk, president of Gap Inc. Direct, the company’s corporate catalog and online division, said the mouse-overs and pop-up windows eliminated the need to bounce the shopper off her browsing path each time she needed information.”

This sounds a lot like what we call Pogo-Sticking, one of our favorite research topics here at UIE. Over the years we’ve seen hundreds of people become frustrated from the repetive act of looking at a list of products, clicking on one to get to a product page, then deciding to look at another product and realize the only way to do so is by clicking the “Back” button and doing it all again. In fact, in 2001 we wrote a whitepaper about it:

Are the Product Lists on Your Site Reducing Sales?

So we’re glad to see the Gap.com team take up the pogo-sticking challenge. Long a frustration on most of the web sites we’ve tested, it is such a core problem of web design that we’re sure that it isn’t going away any time soon. Here’s hoping the redesigned Gap.com might hasten its departure!

When we put together Brain Sparks, we needed to know what the current knowledge was regarding blogs and feeds. Were people familiar with blogs? Did they know what feeds are? Did they recognize that they could automatically get updates of the site whenever we publish something new? In short, how many people already possessed the target knowledge, and how many people were still new to this whole phenomenon?

Of course, someone having the knowledge that they can use feeds to keep track of blogs doesn’t mean that they’re going to choose to do so. Their personal choice is what we’re after, to communicate the topic well enough so they can make the decision of whether or not it is right for them.

In our initial research, which involved talking to people and doing a sort of literature review about how other sites were handling the situation, we realized that there was little consensus about how to handle the notion of feeds. Some people had no idea what they were. Some had heard of them, but didn’t know how they might help. Others were comfortable with them, but called them something else. After reading a lot of different viewpoints, our conceptions of feeds changed, too. We realized that there was barely even a language for talking about them, let alone a standardized way of doing things.

We hope the results of our efforts, the Subscribe page, is hard to miss. On the right hand side of this blog you’ll notice a link to it enclosed in a box titled “Subscribe to Brain Sparks”. This box contains some text that we wrote to satisfy varying levels of knowledge about feeds. If you don’t know what a feed is, you can find out by clicking “What is this?”. If you already know what a feed is, you can simply grab the feed from the link.

Judging from the uptake of our feed so far, we’re happy with how this is working. However, there are still things we can tweak. What happens if someone who doesn’t know about feeds clicks on the feed link and views the raw XML content there? What if someone associates the word “subscribe” with something they have to pay for? What if someone is determined to subscribe to our Atom feed instead of our RSS feed because they like that format better? What if someone reads the subscribe page and it just doesn’t help them?

We’ll be dealing with these questions over time, as we learn more about the current levels of blogging and feed knowledge of the growing Brain Sparks community. If you’ve seen something that works, we would love to hear about it.

‘On www.uie.com, there is a box about the UIE blog. Please correct the grammar to say, “It’s different from..” rather than the incorrect, “It’s different than..”

Yes, it does make a difference. The educated among us place less value on your recommendations if even the most basic rules of grammar are not followed.’

Here’s the image in question:

I’ll be the first to admit that my grammar isn’t perfect. My curiosity, however, wouldn’t let me simply take this person’s word for it and accept that my usage was incorrect. So I did a bit of digging…

My extensive research turned up a comparison of “different from” vs. “different than” on alt.usage.english.org. Apparently, “different than” is used much more in speech than it is in writing and is much more popular in the U.S. than it is in the U.K. Who knew?

After reading this comparison, I feel justified in how I used it in this situation because I stayed within common usage. However, there seems to be two opinions on common usage. One is to let common usage fly, as I did, accepting any and all usage as OK. The other is to hold to strict, agreed-upon conventions, based on past usage but not necessarily current usage.

The Information Architects out there might recognize this as a debate central to the recent advent of folksonomies, a user-driven approach to organizing content. In general, the debate was between the “categorization from usage over time” camp vs. the “categorization by professionals” camp. The debate has since become more nuanced, because there were many more subtleties to it than were first apparent. Not surprisingly, it seems like folksonomies will be useful in some areas, while traditional categorization will be useful in others. (and probably combinations of the two in still others)

Despite my extensive research into the usage of “different than” and my reluctance to give in on account of what is “proper”, the kind reader’s input is still most certainly valuable. Not only did they pay alarmingly close attention to the words used, but they took the time to write in about it. That fact, more than anything else, has persuaded me to update the graphic.

It’s an important lesson, retaught, and it is different from the lesson on grammar. The lesson? Every word matters.

The premise of Blink is that we think without thinking, that our brain is always working even if we don’t realize it. We make split-second decisions about things with very little data. That new neighbor? We already have an opinion about him. That person’s clothes? It does affect our impression of them.

What about web sites? What about our first impressions of using them? Does the story in “Blink” carry over to our life online?

A simple example is how well a web site says “hello” to readers. Is it friendly? Is it indifferent? Does it dress nicely, or poorly? Does it assume that the reader knows something that they don’t? Does it tell people what they need to know to feel confident that they’re in the right place?

Here are three sites that offer a very similar service. But they each have a very different way to say “hello”, and they each produce very different split-second impression. Take a look at all three for a moment and see for yourself:

• BillMyClients
• Blinksale
• Thomson Elite

Now, knowing what you know now about these sites (which isn’t much), if you had to recommend one of these services, which would you choose?

Is there any doubt in your mind?

So, how can you find out how well your site is saying hello? Well, we call a more formal method of investigating initial impressions a “5-second Test”. Christine described the 5-Second Test a few weeks back in good detail.

The 5-Second test is a small part of our ongoing research into what we call “just-right” information. Just-right information is information that is not too minutely-detailed to be useful nor is it information that is too sparse to be helpful. It’s just-right, and part of delivering The Right Information is that it makes a good impression when it says “hello”.

Something is definitely in the air. But what is it? What is the source of this huge amount of energy?

There are many factors, of course. One of the major ones, I think, is an acceptance of the Web as a viable medium, a viable place to do business, a comfort level. Ten years ago it was unheard of for people to put their credit card number into an input box. It was unheard of to do banking online. It was inconceivable to download a file even approaching 1 MB in size. People were suspicious of cookies, of providing personal information, of encryption strength.

Now that we can do all this, however, it becomes very interesting to see exactly what people are comfortable with. Are they comfortable with providing their bank account number? How about their social security number? Or medical information?

With every advance in technology, there needs to be an advance in comfort. We’ve seen in countless user tests that in order to make people comfortable with new technology, they can’t simply be told to use it. They need to have experience with it, to know the incentives, to recognize the work that’s being done to keep them safe.

So, if you’re working on new web applications, do you know the comfort level of your users?

The other reason is that we often use Staples’ homepage as an example when we talk with clients, because they do something that most other companies don’t. Instead of hiding their hierarchy behind a small number of tabs or links on their home page, they expose a great deal of it, using valuable real estate that is often reserved for branding purposes.

Here’s a screenshot of their new homepage, taken today:

Staples continues to use much of their homepage to expose their product categories. This makes sense to us because we’ve seen this approach succeed rather well for users who want to zero-in quickly on what they’re looking for.

Something else interested us about the redesign, too. We were surprised to see that the designers at Staples created a new top-level navigation bar that included a tab labeled “Ink & Toner”.

In the new nav bar, “Ink & Toner” is put on the same level as “Products”, of which it is obviously a subset. This clearly shows that the designers made an important distinction with this product category, giving it higher precedence (and deviating from the hierarchy) by placing it on the top level.

We soon discovered, however, that this design decision might not have been quite the distinction that we first supposed. Take a look at OfficeMax.com. They have an “Ink & Toner” tab, too.

We’ve seen this before. Many design teams, tasked with creating a site that directly competes with similar web sites, often copy features from each other. The general impression is that if your competitors are doing something you’re not doing then they know something you don’t. Better to copy the feature and catch up than to leave it out and risk losing whatever it is they’re gaining.

However, we’ve seen the opposite to be true. We’ve seen those teams that focus directly on their customers succeed the best. After all, there is some reason why they are customers of one company and not the other. A design that reflects that differentiating reason will keep them happier, longer.

In this case, however, we happen to know that Staples rigorously tested this version of the home page with their own users, including the interesting “Ink & Toner” tab. We have it on good authority that this tab is helping their users, not hindering them.

So, even if the Staples design team created the “Ink & Toner” tab because Office Max had one, it’s OK because they’ve made sure that it works for their users. If they had copied it only for fear of missing out and had not tested it, then they would potentially be designing for the wrong customers. And if they came up with it independently, then just as well.

Unfortunately, much of the literature out there doesn’t deal with redesign, but instead deals with design from scratch. While many books will help you design something without having an existing web site, few books deal with how to redesign an existing site and all the issues particular to that challenge.

As a result, we are big fans of Kelly Goto and Emily Cotler’s book: Web Redesign 2.0: Workflow that Works. Freshly updated, this is one of the best books we’ve found that deals with the unique aspects of redesign: including sections on auditing current content, migrating site organization, and iterating an improved design. We’re such big fans, in fact, that we’ve invited Kelly to speak at UI10 this year. Her session is called Web ReDesign Redefined: Strategies for Success.

We’re also really happy to see many of our past and current speakers highlighted in the book. There’s Eric Meyer, one of our current Conference speakers, talking about CSS. There’s Kate Gomoll, one of our Roadshow speakers, talking about User Profiling. And there’s Christina Wodtke, one of our past Conference speakers, talking about IA toolkits. Needless to say, we think this is a valuable resource for teams challenged with a redesign.

Are you involved in a redesign? Let us know how it’s going!