Info Design: Jennifer Fleming on Designing 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.
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.
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
Is infuriated by the request for personal information. None of their
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
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.
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
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
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
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
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