August may mean the Dog Days of Summer, but we have another great UIE Virtual Seminar for you that we think you’ll find very cool:

Galleries: The Hardest Working Pages on Your Site
Date: August 14th, 2008 — 1pm ET / Noon CT / 11am MT / 10am PT

As we continue our series on Designing for the Scent of Information, we take a detailed look at your site’s most critical page: the gallery. Galleries are most used navigational element on any web site and many sites have hundreds of them. And yet, they are often the most difficult pages to design well.

Acting as the crossroads for your users path to their desired content, a solid gallery page tells the user what they’ll find and, just as importantly, tells them which paths will take them away from their goal. Ensuring these landmarks do their job is probably the hardest part of designing a successful website.

I will show you some of the latest design thinking from Netflix, Best Buy, Bureau of Labor Statistics, SonyEricsson, and Citibank, to name a few.

You can read the full seminar details here.

As I mentioned last week, producing a great search results page takes a ton of hard design work. There’s really no way without studying the users’ goals and needs, and watching how they interact with the results the engine generates. In almost every instance, Search is not the user’s end goal, but one tool they can choose to help achieve their objective. Without a deep understanding of their objectives, it’s really difficult to design a great tool for them.

In today’s issue of our email newsletter, UIEtips, I conclude my feature discussion on producing great search results pages. In the article, I share some of the behavior patterns we’ve uncovered as we researched how people interact with the results from a search query, including how they deal with link relevancy and the chunking of results.

This week’s conclusion produces several more surprising results from our research. I’m betting there will be some good discussion that follows.

Read my article, Producing Great Search Results: Harder Than It Looks, Part 2.

As I was writing this week’s article, I kept thinking about all the different skills that come into play when you try to design an effective search results page. Even though it’s just designing a single page, it requires a team with talents and experience in information architecture, user research, visual design, interaction design, analytics, and copywriting.

It’s no coincidence that we’ve assembled world-renowned experts on these topics at our upcoming User Interface 13 Conference, scheduled for October 13-16, 2008 in Cambridge, MA. Make sure to check out the full program at the User Interface 13 Conference.

When you’re watching your users interact with your site’s search result pages, what behaviors have you noticed? We’d love to hear your insights. Share your thoughts with us below.

On his Biznology blog, search expert Mike Moran (author of the great book Do It Wrong Quickly), commented on my recent article about how people search, Producing Great Search Results: Harder than It Looks - Part 1.

In his post, Mike makes some excellent points, including pointing to the seminal work by Andrei Broder, A Taxonomy of Web Search (PDF), which talks about three types of searches: navigational, informational, and transactional. He suggests that my theory that users just want a single result, not a set of choices, is flawed. He wrote:

In my work at ibm.com, I noticed that the most preliminary searches often were informational ones. Someone might search for “e-mail archiving case studies”—they don’t want to get just one. Now, sure, if you have a page on your site that lists every blessed e-mail archiving case study, that would be a great #1 result, but you usually don’t have that kind of aggregation page for every possible query.

Searchers would not want your “Content Management Case Studies” page as #1, even if that list included every e-mail archiving case study, because it also includes too many other irrelevant case studies. Instead, searchers would love a list of case studies that match the query. They could scan through that list and click several results, drinking in that practical information they crave.

I think Mike is correct, if you look from the myopic viewpoint of the query itself. Starting with “e-mail archiving case studies,” the fact that it’s a plural, implies that the user wants a listing. But, that’s assuming that the user really wants to see e-mail archiving case studies.

I suggest that we start earlier in the user’s day. It’s likely that the user didn’t bolt out of bed first thing in the morning saying, “I need to type ‘e-mail archiving case studies’ into IBM.com and see what I get!” There’s some line of thinking and behavior that started this process.

Why does a user want to see the case studies? Are they looking to see that others had gone down the archiving road before them? Are they looking to compare vendors? Are they looking to solve a specific archiving problem (such as regulatory compliance in the pharmaceutical industry), but don’t know how to describe that for a successful query?

In any case, I’m betting that the user would be much happier with a single link that answers their specific need than a selection of links for them to choose between.

Developers trying to make a great On-site Search experience have the problem that they just have a list of queries and a corpus of content. They have to create matches between the query list and the available content.

But when you step back to the original goal of the user and ask what they need to accomplish that goal, you come up a different set of content altogether. The problem with Search is that we force the user to specify their goal in terms of the phrase they think will most likely produce a reasonable result.

Mike is right that the results need to be relevant. (I’ll talk about relevancy in part 2 of the article.) That’s the problem with the Content Management Case Studies result — it’s not really relevant.

But I think he’s wrong when he says that users are sometimes looking for a list of content, if you look at it from the holistic viewpoint of the user’s goal. They may settle for a selection list because of the poor state of what today’s Search experience delivers, but I think that isn’t what they really want.

When you study how designs get made as much as we have, you start to notice something: good design is directly related to effort. Good design takes a lot of work. Bad design, as the bumper sticker says, “it just happens.”

You won’t find this to be any more true than in the design of effective search results pages. Search results look easy. After all, the engine has done all the heavy lifting. It’s taken the user’s query and scoured through the millions of bits of data to narrow the results down to a presentable set. All you have to do now is just display the results, right?

Well, after watching hundreds of users try to accomplish their goals with hundreds of web sites, we can now say, without any hesitation, that it’s not easy to produce a great search results page. In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users.

In today’s issue of our email newsletter, UIEtips, we present the first of a two-part article on producing great search results. Fortunately, having now watched all of these users, we’ve seen some really interesting patterns in how the most effective search results pages pull it off. And, over the next two weeks, we’ll share those with you.

Read my article, Producing Great Search Results: Harder Than It Looks, Part 1.

Search results pages are just part of a site’s information architecture. If you want to ensure your users get to the content they seek, you’ll want to attend Donna (Maurer) Spencer’s full-day, in-depth seminar, Information Architecture Essentials: Best Practices for Organizing Your Site’s Content. This is just one of excellent seminars we’re offering at this year’s User Interface 13 Conference.

Have you been working on your search results pages? Have you noticed design patterns that have made your site more effective? We want to hear about your experience. Share your thoughts with us below.

Usability Tools Podcast: Moderating Usability Tests, Part 1
Recorded: July 3rd, 2008.
Brian Christiansen, UIE Podcast Producer
Duration: 33m | File size: 19 MB
[ Subscribe to our podcast via iTunes. This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Show Notes ]

 

 Usability Tools Podcast: Moderating Usability Tests, Part One [33:22m]: Play Now | Play in Popup | Download

In this episode of Usability Tools, Brian Christiansen and I talk about how to moderate a usability test. Turns out, the episode got so long that we decided to break it into two parts. This week’s show focuses upon the different roles a single moderator needs to take on during the session.

The usability test moderator has a lot of influence on the success of the test. Moderating isn’t rocket science, but you’ll need to understand the basics before you sit down with your users.

In this week’s show, I talk about the three roles a moderator needs to play during the test.

First is the scientist. The scientist makes sure your tasks get done, notes get taken, and keeps the show on track.

Then we have the sportscaster. The sportscaster gives play-by-play so the design team members don’t miss anything the user does.

Lastly, there’s the role of the flight attendant. This is the most important role. Keeping your test participant happy and comfortable is your number one job.

Tune in to learn the specifics of each role and how they affect one another.

If you have questions about the role of the moderator, feel free to ask them in the comments. We’ll try to answer them and may even work them into a future show. Stay tuned for the second part of the Moderating show next week.

[This show is the first in a series we're going to do on the fundamentals of usability testing. In future shows, we'll cover the entire gamut of testing, from initial planning, through task design, to data analysis and beyond. We want to create a complete resource that you'll share with your entire team.]

Yesterday, I talked about how we come up with each row in our Weighted Differences Matrix. For each of these differences, we need to then assess how important it will be to the user’s experience, which we represent with a weight. The weight is a number from zero to ten, where a zero means the feature isn’t important at all and a ten means the design would fail without it. The question then becomes, how do we decide what the weight should be for each row?

The quality of the weights will depend on what information the team already has. In the case of the project I described in my presentation, the first time that team sat down to create their matrix, they had done very little user research (as in virtually none) to work from. So, to some extent, they were going to guess on the weights. However, they had been in business for years with a web site that was attracting millions of visitors a month, so they knew something about their users and the users’ needs. It’s with this information that they’d start the process of assessing weights.

Whether the team has good research to back up their assessment, or whether they are just guessing from their experience, the process is basically the same. Once we have our list of differences (as I explained in yesterday’s post), we assess the weights.

We like to use a facilitator for this process — someone who isn’t going to contribute to the weights and isn’t going to push an agenda. It can be a team member, but they need to understand that they are abstaining from giving their own opinions. (It’s ok if a team member has an agenda they want to push, they just shouldn’t be the facilitator.)

For each difference we’ve identified, the facilitator asks for the votes. The easiest way to make this happen is for everyone in the room to raise their two hands, displaying between zero and ten fingers. The facilitator then calls out each number around the room. (“7, 5, 6, 3, 8, 7″)

Then comes the fun part: The facilitator picks someone who had a vote that was very different from the rest and asks them to explain their rationale. So, if almost everyone was sixes or sevens, the facilitator would ask the person with the lowest vote, say a three, to explain why they rated it so low. Then, the facilitator would ask someone with an opposite vote to explain their rationale. The goal is to get a small debate going to bring out the differences in thinking.

The facilitator can decide when the group has heard enough of the debate. We don’t want to fixate on this, since there is still a lot to do, so moving quickly is a good thing.

After ending the debate, a second vote is taken, again by holding up fingers. Again, the facilitator reads off everyone’s fingers and then declares what the final number should be. We use the “olympic scoring method” by throwing out the highest and lowest scores and averaging the rest.

We like this three-step process (vote, discuss, vote again), because it keeps the proportionate to the differences of opinions. When the team really agrees, the debate is really short. Only when there is real disagreement does the debate take time, but with the help of a good facilitator, it still can go quickly.

(One of the most fun moments for us is when, in the first vote, everyone goes in one direction except for a single dissenting team member. That member shares their rationale and everyone goes, “Oh, of course” and then votes with that person. It’s fun to see a team have a group-wide “aha!” moment like that.)

In Part 3, I’ll talk about how we assess the scores for each design alternative.

When I presented my suggestion for how to compare multiple design alternatives, one step involved creating what I called a Weighted Differences Matrix. In the matrix, each row represents a difference between the design alternative, which, in turn, we interpret to be a factor to help us decide which design is better. How do we know what the list of differences should be?

The process we’d use is to compare the designs side-by-side and list the differences. A method I’m fond of is to do the comparisons with two sites at a time. In this case, we’d probably start with the current design and alternative #1. We’d put them side-by-side and ask, “What makes these designs different?” Once we’d exhausted our thinking, we’d replace alternative #1 with alternative #2 and repeat the questioning, looking for new differences to add to the list.

To be complete, after comparing all the alternatives to the current design, we might try comparing them to each other. However, we can probably just eyeball the different designs to catch the last few differences that we may have missed on the first pass of comparisons. In my experience, 95% of the differences are discovered on the first pass. For most projects, that’s good enough.

Given five alternatives, we’d allocate an hour to generate this list.

Tomorrow, we’ll talk about how we would assess the weights for each difference.

In the corporate boardroom, Innovation has moved beyond the fad stage and has now become an enterprise mandate. Problem is, ordering your institution to innovate is akin to a gym teacher ordering the class to meditate. (“OK CLASS, TODAY WE’RE GOING TO MEDITATE. BEGIN. ONE. TWO. MEDITATE. THREE. FOUR. MEDITATE. SPOOL! YOU’RE NOT MEDITATING!” Is my high school phys ed experience showing?)

In the June 2008 issue of the Harvard Business Review, there is a super article by IDEO’s Tim Brown on what it takes to bring innovation down to the execution. Tim’s solution: Design Thinking.

Tim tells us that Design Thinking is:

a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

Anyone who is immersed in UX design will find familiar comfort in Tim’s descriptions of how this works. There’s nothing new is how he goes about it. It’s just that he’s done a great job of explaining what we do in business terms that executives can understand.

For example, the Tim explains why prototypes are important to an organization’s understanding of the problems they are trying to solve through design:

Prototypes should command only as much time, effort, and investment as are needed to generate useful feedback and evolve an idea. The more “finished” a prototype seems, the less likely its creators will be to pay attention to and profit from feedback. The goal of prototyping isn’t to finish. It is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take.

If you don’t have a Harvard Business Review premium subscription, it will cost you $6.50 to get the PDF of this article. However, if you are looking for a good way to help your senior management team understand the value of design, this article will be well worth it.

Access the Harvard Business Review Article, Design Thinking by Tim Brown.

Last week, I spoke at the Boston IxDA night of Short Talks, where I gave a 10-minute (!) presentation called Case Study: A Discount Approach to Comparing Multiple Design Alternatives.

Here’s what the session was described as:

What’s the Best Way to Compare Multiple Design Alternatives?

Good design practice suggests you create multiple sketches, which eventually evolve into full-out design alternatives. However, once you have those alternatives, what’s the best way to decide which one wins?

I will review one approach and talk about the pitfalls and advantages to evaluating multiple designs at once.

Because of An Event Apart and our Virtual Seminar, I didn’t have as much time to prepare as I would’ve liked. So, I ended up creating the entire presentation while sitting in the back of the room, waiting my turn to present.

Here’s how it turned out:

| View | Upload your own

I should mention that the subject of this talk was inspired by the UIEtips article, A Counter-Intuitive Approach to Evaluating Design Alternatives, published on May 19. Thanks to Pauric for inviting me to the meeting to present the idea.

We’ve got another great UIE Virtual Seminar coming up:

The Scent of a Web Page: The Five Types of Navigation Pages
Date: July 17th, 2008 — 1pm ET / Noon CT / 11am MT / 10am PT

You work hard providing top-notch content on your site. Will your users find it? If they don’t find it, all that effort is for nothing. What can you do to guarantee that users find the content they’ve come
looking for?

In July’s UIE Virtual Seminar, I’ll present our most up-to-the-minute research on how users navigate sites. You will learn best practices for designing the different types of navigation pages, including the Home Page and Content Pages.

You’ll come away from this seminar understanding why trigger words are critical to users successfully finding their content, why the best sites prevent users from using Search, how exposing a site’s hierarchy can increase the success of the user, and how designing longer pages helps users find what they seek.

You can read the full seminar details here.