Ships from: Cambridge, MA
Usually ships in 1-2 business days
Web Navigation: Designing the User Experience offers the first in depth look at designing web site navigation. Author Jennifer Fleming offers design strategies to help you uncover solutions that work for your site and audience.
Acclaimed Web design author Lynda Weinman says in the foreword to this book: "Kudos to Fleming for her excellent research, approachable tone and generosity of information. If you're looking for help in giving your site's visitors a more positive experience than they get today, this book is an excellent place to start. It provides ideas and direction, not preachy rules that apply to someone else's site."
The first half of the book suggests goals and processes for developing workable navigation schemes. Topics include:
The second half of Web Navigation focuses on designing by purpose, with chapters on entertainment, shopping, identity, learning, information, and community sites. Through case studies and interviews, each section explains common navigation problems and presents real world solutions and advice. Designer interviews feature conversations with industry leaders such as Clement Mok, Jakob Nielsen, and Nathan Shedroff. Case studies include sites such as FAO Schwarz, National Geographic, and IBM.
The accompanying CD-ROM is more than just a handy drink coaster. It serves as a launchpad to the sites mentioned in the text, and also offers software demos and a "netography" of related Web resources. "The Web needs more books like this if it to evolve to the next level," Weinman writes. "I believe this book can help you make your site a better place, regardless of whether your purpose is community-building, commerce, education, entertainment, information, or hobby. It's written is such an enjoyable, conversational tone that you may have trouble putting it down; I certainly did. I wholeheartedly recommend it for all Web publishers."
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 profilesImagine 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: GeorgeGeorge 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: NatashaNatasha 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 scenariosThinking 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.
Bad navigation is like a roach motel.
Users go in, but they can't get out.
-Doren Berge, Lycos
With so many software programs promising a site in a box, it's easy to believe there are quick formulas for success. But this isn't Minute Rice we're talking about (regardless of how good our tools get). There are no simple recipes for navigation design. Two parts Magical Mouseover Beans mixed with one part Interactive Image Map don't necessarily add up to anything. There is no Joy of Cooking for the Web.
Looking at successful navigation, however, can shed some light on qualities that are consistently shared. These don't add up to a formula, but they can help us understand the principles behind our design choices.
Navigation that works should:
Navigation should be easily learned.
Your content might be wonderfully mysterious, but getting to it shouldn't be. If your visitors have to spend time learning how to use a complex navigation device, they won't have much energy left to absorb your content. What's more, they're not likely to bother trying -- not for long, anyway.
People who have sunk $500 into a software tool will usually take the time to learn it, even if (like Photoshop or Microsoft Excel) it's famous for having a bit of a learning curve. The same is not true of the Web, however. Visitors don't feel the same sort of ownership of a Web site that they feel about a software tool, and so there shouldn't be a learning curve. Users won't put up with it.
In navigation design, then, it's best to avoid burdening your users with a steep learning curve. Take on the extra challenge of making your system easily learned -- of making it transparent and obvious to your users. If the noble pursuit of user-centered design is not enough, then simple business sense should be: people won't stick around if you don't serve them well, and you only have one chance to make a first impression.
Navigation should be consistent.
If you develop a navigation scheme that works, users will come to rely on it. Make sure your approach to navigation is consistent, or you may unwittingly confuse your visitors. The ability to predict where navigationals will be found is an important first step in making choices.
People will often put up with quite a few other navigation quirks so long as you're consistent in your offerings, their placement, and their appearance. It's the Hansel and Gretel factor: nobody likes to feel lost, and the quickest way to make someone feel lost and disoriented is to take away something they were relying on for direction. Sweep up the bread crumbs, and the fairy tale tykes are lost. Move or change the navigation from screen to screen, and your users are lost.
One common error on the Web is the disappearing navigational, a menu option or button that seems to appear or disappear as it pleases. Often this is intended to be helpful: some designers remove an item from a navigation menu when users are on the page it corresponds to. The intent is good, but the result is poor navigation design. Users confronted with a menu that seems to change from five choices to four, or ten options to twenty, will become disoriented. They'll lose their trust in the navigation aids, and eventually, in the site.
Instead, developers who want to be more responsive about location should consider shading out the current position, making it visible but not clickable. This maintains consistency without needlessly confusing users.
It's also important to keep things in the same place across your site. Your main site navigation menu might be at the top, for example, with subtopic navigation to the right. If you suddenly decide to put your subtopic navigation on the left, you'll throw off your users. They're expecting to see it where they saw it last -- and that's where you should put it.
Another threat to navigational consistency is what I think of as the breakdown point. Every developer has probably encountered the breakdown point -- the magical point where navigation breaks down due to poorly planned architecture, an overcrowded screen, an overabundance of information, or other factors. It's a frustrating point, and some developers respond by tacking on an extra bunch of links or just continuing to add menus and lists willy-nilly.
Rather than letting chaos rule three or four layers into your site, work it through instead. Find a solution that is consistent with the choices you've already made, and work with a good site architect to delve into those troublesome buried layers. Consistency is not just a guideline for your top-level screens, but for every area of your site.
If a certain section or piece of content can't be kept consistent with the rest of a site (for example, if the content requires some sort of special navigation), consider building a subsite. A subsite is a separate area of your site that has its own look and feel and usually its own approach to navigation. A subsite can sometimes be the best solution to managing a very large, information-rich site with numerous departments. IBM (www.ibm.com), for example, uses multiple subsites that are tied together with a few standardized layout elements (including the familiar logo).
Navigation should provide feedback.
We're conditioned to expect reactions from things (and people, too). Push a button, a doorbell rings. Turn a knob, the music changes. Getting through our everyday interactions is based on evaluating feedback. It's the same with navigation. Feedback is often the only way we can tell whether we've been successful -- whether we have arrived.
Designing navigation feedback includes creating controls that are responsive (ideally, in the way that many of life's knobs and buttons are responsive) and in providing information about location. Both types of feedback are essential to users, since both help them judge their success or failure in moving through a site.
Rollovers (or mouseovers) are one good way to provide responsive controls. With a rollover, passing your mouse over an object on the screen causes it to "react" -- whether by revealing a set of instructions about that image, animating, or simply lighting up. This is good human factors design, assuming it's used to show active items and not just as an indiscriminate gimmick.
Showing location is far simpler than implementing a rollover script to get responsiveness. A sense of location can be established with something as simple as a second version of a navigation image, darkened or lightened to show that "you are here." Other methods include using an arrow or pointer to show the current position, or if a text menu is being used, making the current position unclickable. These are simple methods, but can be crucial to users' success.
Navigation should appear in context.
To complete tasks, people need the right tools at hand. To make decisions about movement, they need to see possible routes. Navigation should always be available when it's needed, since people shouldn't have to rely on browser features or guesswork to move around.
Part of understanding context is understanding the uselessness of most "back" links. Users are accustomed to the browser's back button -- it takes them back to the last page they saw, regardless of where that page lies within the site plan. With users coming into your site from the front door and following a set path in and out of your site, "back" might nicely correspond to exactly what they think it will. But this is a dream world, since most visitors are unpredictable, come in from the side or bottom as well as the top, and may not follow a military march through your site. Taking these things into consideration, "back" begins to sound a bit hazy.
With proper context and explanation, a back link can work. "Back to the such-and-such-page," for example, is not so bad. "Go to the such-and-such page" might be even better for some situations, since it doesn't imply any particular starting point. "Start game over" might be a descriptive solution for a gaming site. "Go to the lobby" could work if you're using that metaphor. Being descriptive and avoiding highly relative terms like "back" or "top" is the best approach, unless you have a completely linear presentation.
Another part of providing navigation in context is understanding where people will be when they finish doing things. When they finish reading a long article, for example, will they need a link back up to the top? When they click on an image to see a larger view, will they need a link back to the thumbnail? When they download a piece of software or fill out an online form, where will they end up when it's over? Considering these questions helps you design navigation that is available when it's needed.
Navigation should offer alternatives.
Users are different, from their computer equipment to their personal preferences, and so you may need to explore navigation alternatives. Incorporating alternatives such as low-end site versions, site maps, or search boxes can help match various user behaviors. Be careful to balance this with managing clutter, though -- too many options is as confusing as too few.
Providing alternatives has a lot to do with accessibility. Often "accessibility" is thought to be synonymous with disability, but it's much more far-reaching than that. It's as important that you try to meet the needs of a blind visitor as it is to meet the needs of someone who doesn't have the Shockwave plugin. Whatever the specific reason for being locked out of content, the effect is the same.
There are some basic techniques for promoting accessibility that don't require much extra work. Avoid locking important content, especially navigationals, in a proprietary format (such as a Flash movie or JavaScript rollover that can't be viewed in MSIE 2.0). The same goes for images -- locking in content without using ALT tags is unnecessarily restrictive.
In some cases, using browser or object detection can help to make sure things go smoothly. Detecting for a certain plugin, for example, could help reduce the chance that someone was later bombarded with insulting error messages. This usually means building several versions of your site, though as the Web becomes more and more object-oriented, it should just mean building templates. For the time being, though, the best approach if you desperately need to use a proprietary component is to construct an alternate version of a site. Constructing an alternate version that simply says, "Sorry Charlie, but your browser/equipment/connection/life stinks," is not a workable solution for a professional developer... and it certainly isn't workable for the people who are faced with it.
The added benefit of detection is that often new users don't know what sort of equipment they have. Offering them the chance to pick their route -- "high-calorie" or "lowfat" are popular choices -- is often a puzzling crossroads. In some cases, people may not know what browser they are using (I've watched it happen more than once). Offering control to users is always a good idea, but where it could get confusingly technical, it's best to offer guidance instead.
Navigation should require an economy of action and time.
In cars, planes, or on the Web, people lose interest on long trips. Remember all those car trips you took when you were a kid? The scientific term for this delicate condition is "Are We There Yet?" syndrome, and it's roughly synonymous with acute frustration.
A site structure that features layer upon layer of subcategories with many levels to click through can induce "Are We There Yet?" syndrome. So can a situation in which there are a ridiculous number of steps to complete before any serious content can begin (such as a prolonged login process or time-consuming shopping cart). Forms, especially long forms, are a source of frustration for many users, since they are perceived as not only a potential threat to privacy but a potential waste of time. They're one of the more obvious barriers you can place in front of users, especially if you put them right at the front door.
Forms that go across pages are also potentially troublesome. Users may not know how many screens they will need to complete, how many more questions or steps the process entails. Because of these uncertainties, many people retreat when faced with a form. You can make their life easier, though, by being selective and focused in what you ask of them, and in communicating how long it will take people to complete the form, why the information is valuable, how they might benefit, and what the rest of the process will entail.
Without navigation shortcuts, "Are We There Yet" syndrome is almost sure to kick in. Navigation shortcuts -- whether in the form of a site map, index, contents list, or pull-down menu -- are especially essential for complex sites. The deeper and wider the site, the more likely it is that users will protest at having to burrow through numerous intermediate pages. Allowing users to jump quickly from one corner of a site to another is a part of maintaining an economy of action and time.
Navigation should provide clear visual messages.
Interface design is not just about beautifying. It's visual guidance. How you present navigation options is closely tied to how usable they are. If they're hidden, difficult to find, look too much like text, look too much like other images, or are otherwise visually confusing, your users will have trouble getting around.
Visual hierarchies are one way to provide this guidance. Movement, color, position, size, and other factors help people judge items and make choices. Understanding things like metaphor and semiotics can also be very crucial.
There is an ongoing debate over whether we have a "visual vocabulary" or set of conventions we can use on the Web. In other media, such as book publishing, we have conventions such as page numbering that help us to orient ourselves. In travel and tourism, we have icons for restrooms and restaurants and gas stations. We do have some web conventions, such as as underlining of text links. Generally, though, almost everything has been up for grabs.
This can make it difficult to get around on the Web. As Clement Mok, founder of Studio Archetype (www.studioarchetype.com), pointed out, "If you're coming in from the world of print, navigation is implicit. You already have a set of vocabulary that you've learned over and over again, a variety of conventions that help people get from one part of a book to another part. Pagination, structure, a table of contents: these implicit structures carry over, and we take them for granted. That set of conventions does not hold as true on the Web. One has to go out of the way to make it clear."
"Right now, in the absence of Web conventions, we're relying on crutches," he continued. "The house icon is about home, and so on. This situation is partly the result of technical limitations in giving the physical sense of space in three dimensions. The minute you have that, I think some of the more lame conventions of underlining and 'home' will probably go away. At some point, it will become very implicit, but there is no set convention at this point in time."
Despite the underdeveloped visual conventions of the Web, we are still subject to a larger cultural visual vocabulary. Whether we intend it to or not, there is visual meaning in much of what we create. For example, a graphic might look like a navigational button because it appears to be three-dimensional. A clickable word, created as a graphic, might appear to be just plain text rather than a link. Visual messages communicate ideas about tone, purpose, or audience that are essential to how we perceive a site.
Navigation should offer clear labels.
Navigation labels -- like the supermarket labels that prevent you from swallowing something you really shouldn't -- are an important part of communication. Good labeling is more an art form than a science, since it's based less on a standard thesaurus of usable words than it is on common sense and customer sensitivity.
Andrew Chak, Chief Information Architect at Quadravision (www.quadravision.com), related a story that shows how as developers we sometimes take labels for granted. "We once designed a site that had a restaurant finder in it," Andrew explained. "Within the navigation bar, we had a link for the 'site map.' In this particular context, users thought that the site map was an actual map of the restaurant (its geographic location), not a map for the web site. The term seemed reasonable to us as developers, but it wasn't for these users in this context."
In selecting labels, it's best to use the terminology of your users, not cool hieroglyphics, office shorthand, or organization-speak. Dead ends and misunderstandings are a waste of time for your users, but they're all too common when terse one-word labels leave so much open to interpretation.
What's the difference between "clients" and "projects," for example? Or "home" and "top"? Or "help" and "FAQ"? Many of these unnecessary ambiguities could be avoided by better, more precise, and more descriptive labels. Not all misnomers and ambiguities are foreseeable, but some you can predict.
Often, ambiguity or confusion exists because no label is present at all. Icons are common in navigation design, but most have various interpretations. What does a question mark icon mean, for example? Does it imply you can search? Read a FAQ? Submit questions? Is it a help screen? The icon itself has many possible meanings, and there is no reason your users should need a pocket Rosetta Stone to use your site. Adding text labels to icons is a simple and effective solution, assuming the text label doesn't introduce further ambiguity.
What about the "cool" labels designed to pique our interest and prove how funky the site is? The artful use of linking and labels gets to be a bit tricky, since when it's done well (such as Suck's linking out mid-sentence to point at some interesting factoid; www.suck.com), it becomes part of the story. When it's done poorly or inconsistently, though, it's maddening -- much like listening to two people share an "in" joke. What is the difference between mystery and frustration? It's often a very fine line. Getting reactions from users can help you understand if you've crossed it.
Another common Web quirk is the carryover of ridiculously inappropriate organization-speak into Web communication design. Coming up with navigation labels that seem as if they're peeled from someone's office door or copied from an org chart is a pretty surefire way to lose your visitors. Why say "Department of Targeted & Interstitial Marketing" when you could say, "Ad Sales"? One of my favorite professors in college used to say, "Never use a big, clumsy word if you can use a small, clear one. Never choose to confuse if you can instead clarify." Insider jargon, especially organization-speak, can be a serious barrier to communication.
Navigation should be appropriate to the site's purpose.
Your navigation approach will depend a lot on what your goal is and on what your users will expect to accomplish. An shopping site will not necessarily have the same sort of navigation solution as an information site, for example. If your main focus is moving visitors comfortably through a shopping process, your approach may be quite different from a site that needs to provide fast, up-to-date computer virus information.
Mismatches between the site's purpose and the navigational approach can be a cause for user confusion. A good match will mean that the site's navigation reinforces the site's purpose and is integrated with the overall experience. Using a mysterious icon-based navigation approach for that virus information site will keep people from getting what they need. They're not looking for a game or a puzzle. Chances are they're preoccupied with figuring out why all their Word files are suddenly written in Greek, and they're probably not in the mood for laughs.
On the other hand, using a mysterious iconic navigation approach was perfect for the Riven Journals (journals.riven.com), an entertainment site where solving puzzles is part of the game plan. The mood of the navigation, which is both pleasantly mysterious and very usable, supports the entertainment purpose. Designing a buttoned-down navigation scheme that allowed Riven users to go directly to the answer would definitely have spoiled the fun.
Navigation should support users' goals and behaviors.
If you read the last chapter, you already know that navigation is about supporting users' goals -- in particular, your users' goals. What will people want to do? How might they behave? Understanding these goals and behaviors is the most important step in designing navigation that works.
How can you be sure how users will act, though, and what they really want? You can use scenarios, which were covered briefly in the last chapter. Focus groups, ethnographies, observation, and interviews are also immensely valuable. User testing at several points in the process is essential. We'll go into each of these methods in the next few chapters, since they represent the most valuable source of knowledge you have -- more important than what your clients can tell you, more important than survey data. They're the key to successful navigation design.
Recap
There are no easy answers where navigation design is concerned. It's a difficult area, and one that requires a lot of planning and forethought. What works well for one site may be all wrong for another. If there are no simple formulas, how do you know where to begin?
The answer is in understanding not which navigation solutions work, but why. The design principles in this chapter are based on the need for feedback, accessibility, alternatives, and other important considerations. Balancing these principles with the needs and goals of your audience will help you design navigation that works.
Web Navigation: Designing the User Experience provides a method-ical approach to arriving at answers that are right for you-not for some mythical, one-size-fits-all web site. Beneath the useful structure and methodology is an effective system designed to help you outline your own goals and find personalized solutions for meeting them. As you read this book, you'll find many new concepts-such as designing for multiple audiences, building community, conducting user testing, or planning for commerce-demystified. Jennifer Fleming presents each subject in an extremely accessible manner and offers many exercises to help you identify which navigation approach is appropriate for your type of site.
Kudos to Fleming for her excellent research, approachable tone, and generosity of information. If you're looking for help in giving your site's visitors a more positive experience than they get today, this book is an excellent place to start. It provides ideas and direction, not preachy rules that apply to someone else's site.
The Web needs more books like this if it is to evolve to the next level. I believethis book can help you make your site a better place, regardless of whether your purpose is community-building, commerce, education, entertainment, information, or hobby. It's written in such an enjoyable, conversational tone that you may have trouble putting it down; I certainly did. I wholeheartedly recommend it for all web publishers.
-Lynda Weinman,
Author, trainer, columnist
www.lynda.com
Overview
Web Navigation: Designing the User Experience offers the first in depth look at designing web site navigation. Author Jennifer Fleming offers design strategies to help you uncover solutions that work for your site and audience.
Acclaimed Web design author Lynda Weinman says in the foreword to this book: "Kudos to Fleming for her excellent research, approachable tone and generosity of information. If you're looking for help in giving your site's visitors a more positive ...