Mulit Edit:  When it's time to get down and dirty with your code.

Go to: Contents

Go to: Updates/Events

TOOLS OF THE TRADE - Enter the Web Tools Store

tracks
Strategy
Information Design
Visual Design
Usability
Programming
Backend

Go to: Reports on Sessions / Tutorials


Go to: Conference Site


Go to: Test Drive New Tools


Go to: Dr. Dobb's Technetcast

webreview.com @ web 98 Boston Where's Web Review?


Info Design: Jennifer Fleming on Designing Web Navigation

Web Navigation

Crafting the User Experience

by Jennifer Fleming
Sept. 21, 1998

In this excerpt from Chapter 1 of Web Navigation: Designing the User Experience, Jennifer Fleming tells us that good navigation is about meeting users' goals. If you want to design successful navigation, you have to put yourself in the user's shoes. Jennifer outlines how user's goals can be radically different from company goals and warns how following the latter can lead to an unnavigable site. She shows you how user profiles can help predict problems, and starts you thinking in scenarios, all part of crafting the user experience.

Putting yourself in user's shoes

If all Web users were the same, and all of their goals consistent, we could probably stop our planning at the basic needs level. Thankfully, we're not all the same. We want different things, and for different reasons. In navigation design, then, we have to go beyond basic needs and look at specific end goals.

In Web development, we're accustomed to analyzing company goals. Often, our paychecks depend on it. More importantly, it's part of being a responsive and effective designer.

That loyal analysis of company goals can sometimes get us into trouble -- unless, that is, we also take the time to examine the goals of the site's intended users. Lumping client goals with user goals is a serious blunder, since they are often very different things. Designing for clients without calculating for end-users is one quick path to an unnavigable site.

Take the example of a typical shopping site. A developer signs on to help a record store set up a Web storefront. In the early stages of discussion, the developer quizzes the client on their mission and goals, their needs, and their concerns. In service to the client, the developer then spends three months creating a site that will meet every one of these needs and then some. The client is thrilled at the result. When the site premieres, however, the client receives a flurry of email from disgruntled consumers. From server logs, the developer can tell that customers are not making it very far into the site. Sales are practically nonexistent. Six months later, the client abandons the Web storefront, convinced that Web shopping is a terrible farce.

What happened? No one stopped to consider the users' goals, and how they might be different from those of the company.

The seller and the buyer can sometimes have radically different goals. The following chart shows the different goals that might be held by a record store and a user.

Site User

Wants to make money on the Web.

Wants to find out about customers.

Wants to offload 6,000 overstocked copies of Sheena Easton's last record.

Wants to purchase securely.

Wants to retain privacy.

Wants to buy the new Smashing Pumpkins CD.

If the storefront design proceeds with only the client's needs in mind, what's going to happen? The following chart gives an idea.

Site User

Requires users to pass through an "On Sale Now!" screen that promotes the discounted Sheena Easton records.

Rushes shoppers to the checkout and locks them into the ordering process.

Asks for personal information on preferences, buying habits, and income.

Is annoyed with having to look at a promotional screen. Just wants to find the Smashing Pumpkins CD!

Panics on entering the checkout process, since questions about security still haven't been answered and there seems to be no easy way to change one's mind.

Is infuriated by the request for personal information. None of their business!

What's the likely end result here? No sale. A lack of understanding and communication is this site's main problem -- it's not some vague fault of Web commerce. But what does this have to do with navigation?

Everything, really. The user in search of the new Smashing Pumpkins CD had a primary goal, and that goal should have been driving the process. The developer and the client should have sat down (with users if possible) and thought through what people might want and expect from the site, and how they would behave. Avenues designed to help shoppers meet their goals quickly and easily could have then been created.

Without this focus on shoppers' goals, there are unnecessary (and often insurmountable) obstacles in the paths of visitors. What's more, when users can't meet their goals, the client is the one who ultimately suffers the most -- in lost sales, lost customers, and a sometimes substantial lost investment.

If you accept the premise that you need to understand user goals and design accordingly, the next question is: How do you do that? This is a question we'll keep coming back to in the book, but there are two methods you can start with: Creating profiles and thinking in scenario.

Creating profiles

Imagine you've come up with a terrific idea for a site: An online matchmaking service. You've spent some time exploring possible technologies and you know you can make it work. But what would people really want from a matchmaking site? What are their goals, besides getting hitched? Coming up with some user profiles can help fill in the gaps.

User profiles are brief studies of the sort of person who might visit your site. They're a little like a character study in acting or literature, in which you try to put yourself into someone's shoes in order to understand them better. They aren't meant to replace focus groups or user testing. Instead, they act as guides throughout the design process, and help keep human factors at the forefront.

Taking the example of the matchmaking site, you might brainstorm profiles for two fictional users who represent part of your target audience.

Profile #1: George

George is in his early 40s. He works full-time at an insurance agency and has recently divorced. He's definitely leery of jumping back into the singles scene. He lives in a small, tight-knit community, so he's also very worried about privacy. He's interested in finding a match who shares his religion, and he doesn't want to have to relocate. He loves opera and travel and wants to find someone who shares his interests. George will access the site from his home computer, which is a couple of years old and has a slow Net connection.

For the last three months, George has been trying more traditional dating services, without much luck. He complains to friends that it's difficult to select a date based on a video segment or brief description, and he's had a few embarassingly bad dates as a result. He wishes there were a better way to find out about people before meeting them face to face. George is not sure that a Web matchmaking service will work, but he'd rather do that than go bar-hopping.

Profile #2: Natasha

Natasha is 21 and in her last year of college. She heard about the matchmaking site from a friend and thinks it would be a fun thing to try, since academics don't leave her much time to meet people. She's not really interested in a serious relationship, and location is not important to her since she'd be just as happy talking with someone by email as in person. But she's definitely leery of getting mixed up with a weirdo, even though she's pretty savvy about the Web and uses chat services frequently.

Natasha will access the site from her college's computer lab, which has a high-speed connection but does not allow students to install browser plug-ins. By default, Java is turned off in the lab, and security software deletes any unauthorized files (including cookies) from the computers every night.

The profiles of George and Natasha may seem very different, but even from sketching out these two very basic profiles, you can already see shared concerns, which demonstrate the type of patterns you should look for. In this case, both George and Natasha are worried, to some degree, about privacy. Natasha wants to be sure she can avoid "weirdos," and George would be horrified at the idea of his community finding out he was looking for love online. Privacy, then, should become a central issue in the design of your matchmaking site.

You can also predict other things from these profiles. For example, you may need to build in search capabilities for things such as religious affiliation or location. You may decide to avoid using certain technologies or plug-ins. Or you may decide to put your mind to a particularly interesting problem -- such as George's wish that there were better ways to find out about someone before meeting them in person. User profiles can help you predict people's problems, but even more importantly, they may also lead you toward surprising and innovative solutions.

Thinking in scenarios

Thinking like your site's users is harder than predicting New England weather, but scenarios can help. Scenarios, or possible situations, can offer you a view of the navigation process as a whole. Thinking in scenarios also fits the view of a site as an active place for people to move around in. You'll be surprised at what you can learn if you take the time to sketch out some scenarios.

For example, let's take the user profile of George, created earlier. If we have this fictional (but representative) user, how would he move through the site? What barriers might he encounter along the way, and how can we remove them? Add predictions about action to a user profile, and it becomes a scenario.

George is ready to give the matchmaking site a try. He connects to his ISP on his home computer and goes to the site. He's a little nervous about the whole process. Right away he looks for some instructions describing how this works, and he wants to be able to try the service before he signs up. He's also looking for some sort of reassurance about privacy.

If George doesn't find all of these features very close to the front door, he may not continue. Assuming George can find them (since you now know you'll need to build them in), let's keep going with this scenario.

George signs up as a trial member. He's able to pick an alias, which helps him disguise his real identity until he feels confident about meeting someone. He didn't have to give a credit card, but was able to take a tour of how the service works. He's feeling pretty good so far. Now he can focus on finding a match. He figures the best place to start is with the things that are most important to him: religion and location.

Again, if George doesn't have the ability to search the way he wants to search, he may become frustrated with the service and go elsewhere. You'll need to build flexible search capabilities into your matchmaking site if you want to please George. Let's assume you go one step farther, and build in some interesting personality searching.

George does a search by location, and then is able to modify those results by religion. He's left with 150 possible matches who share both his location and religion. That's a lot of results to wade through. George notices another search feature that allows him to modify results by other factors such as personality and interests. He selects some personality traits he values, and then views his results. It's down to 60 possible matches. Finally, he modifies his search so that only opera lovers appear on the list. Now he has a manageable list of 18 possible matches. He begins clicking on their aliases to find out more.

Reading the first few matches, he finds several he'd be interested in meeting. He stops to scribble down these aliases on a scrap of paper near the computer.

If George were able to store possible matches on the site somehow, he might have an easier time of it. Scribbling aliases on scraps of paper isn't exactly ideal. Let's assume you build in the ability to tag and store possible matches, plus a few extra perks.

George tags five of the possible matches to contact later when he has a bit more time to explore. He's relieved to see that there are reassurances about the privacy of his choices. He also notices that if he becomes a full member, he can check to see if anyone has tagged him! He won't be able to see who, but he thinks this could be a lot of fun.

George quits for the evening with a pretty positive outlook. He may not have such a smooth time of it when it comes to actually meeting someone, but so far, so good.

Working through this scenario, you've probably learned several new things about how to design your matchmaking site. Starting with scenarios has given you a better sense of the landscape of your site, and the routes you'll need to build within it.


Yin and Yang: How to Balance Designers' Innovations with Users' Expectations

Crafting the User Experience

Designing for Users

Web Review copyright © 1995-99 Songline Studios, Inc. Web Techniques and Web Design and Development copyright © 1995-99 Miller Freeman, Inc. ALL RIGHTS RESERVED


Click Here for Web Security from Verisign