Goal-Oriented Navigation Design

by Kevin Knabe

from News & Views, Society for Technical Communication, Philadelphia Metro Chapter, April 2001

The role of an information architect often isn't fully understood, even within software and web development organizations. At one company I was sometimes introduced to teams as "our navigation guy." I'm actually okay with "navigation guy" as an informal working title, provided it comes with the understanding that navigation isn't something that can just be slapped onto a system, but rather one aspect of a broader user-centered design approach.

Goal Orientation

User-centered designs are based on an understanding of users and their goals. They bring together a user's representation of a goal (how the user thinks about what he or she is trying to do) with the system's representation of that goal.

When a design does a good job of representing user goals, the solution seems obvious. You want to print a document, and the interface displays a button labeled "Print." You want to check the status of an order you placed with an e-commerce site, and the first item on the site's Customer Service page says "Where's my order?" Of course. How could anyone not have designed it that way?

Yet all around are designs that are fundamentally flawed because they aren't goal-oriented. Product documentation often suffers from feature orientation, which forces users to think in terms of marketing features or the product's underlying technical architecture. (Sometimes feature descriptions masquerade as tasks, with topic names like "Using the Options menu.") Corporate web sites are notorious for "org-chart orientation," which forces a user to think of information in terms of which department within the content development organization produced it.

Note that goal-orientation is similar to task-orientation, but also subtly different from it. A goal is what you want. A task is what you do to achieve it. I might have a goal of a snow-free driveway--and to achieve this goal, I might perform the task of shoveling my driveway. But shoveling the driveway is not what I want; it's not my goal. In fact, I might be able to achieve my goal without performing the task at all (by hiring someone to plow my driveway or waiting for the snow to melt).

User Representation of Goals

Goal-oriented navigation design grows out of effective user and task analysis. Ideally, a design team will conduct contextual inquiries or some other form of user interview to get at what users want to do and how they think of their tasks. But even in the absence of this kind of investigation, designers can serve their users by looking at information from the perspective of user goals.

Suppose I want to read a book, and suppose the room I'm sitting in is too dark. I decide to turn on the lamp. When the lamp doesn't go on, I figure that I probably need to change the light bulb. Then I go look for a light bulb in the hall closet.

What I've done in the course of this relatively simple task is form a hierarchy of goals -- both real-world goals and system goals. (The system in this case is the lamp.)

Now suppose I pass my wife in the hall, and she says, "What are you trying to do?" What she has asked me essentially is what is your representation of your goal?

I'd probably respond with something like, "I'm looking for a light bulb," because that's the most specific goal representation I could come up with. (Had I not narrowed the problem to the light bulb, I might have responded with something else like, "I'm trying to get that stupid lamp to work.")

System Representation of Goals

In goal-oriented designs, the building blocks of the design are representations of user goals. Goal representations can take various forms, including verb phrases, noun phrases, or graphics. Some examples are listed below:

Implications for Navigation Design

Large information systems can support hundreds or thousands of different user goals. A navigation system should be structured in a way that allows a user to access support for a specific goal as quickly as possible. Each bottom-level item in the navigation system should somehow be a representation of a user goal, and category labels should somehow represent higher-level goals or categories of related goals. (For example, on a jobs site, the item "Edit Resume" appears within the category "Find a Job.") Thus, the category structure of the navigation system follows the structure inherent in the relationships among user goals.

In addition, goal-oriented navigation designs should follow these standard navigation design heuristics:

• Avoid deep information hierarchies. Keep all critical information within three clicks.
  
  
• Choose link labels that are predictive, differentiated, and short.
  
  
• Design screens for scanning. Apply information mapping techniques to create prominent goal-oriented headings that allow users to skip to the information they want.
  
  
• Make text easily legible. Use a good screen font at a reasonably large size (12 points or larger). Avoid low contrast text and inverse text.
  
  
• Give users a constant sense of where they are. Use a consistent navigation device (such as a navigation bar) with elements that change to give feedback regarding the current location.
  
  
• Make it easy to backtrack and recover from errors. Allow users to change direction without backing up to another screen. At the same time, provide prominent back functionality (for instance, in the form of a "breadcrumb trail").

Implications for Usability Testing

Evaluation of navigation designs should ideally incorporate both quantitative and qualitative methods. Sometimes its possible to draw inferences about user goals and navigation behavior by analyzing click stream data or web traffic reports, although the usefulness of this kind of data varies greatly among technology platforms.

Observational methods, namely usability testing, can give rich insights into user goals and identify areas for improvement in navigation design. This can be accomplished through standard usability testing methodology (observing a small sample of 6-8 users thinking aloud while doing assigned tasks).

Usability testing of navigation designs is most valuable when the tasks are designed in a way that requires users to form their own goals and tasks.

Suppose you wanted to test the online help for formatting a floppy disk. In a usability test, you could give participants an unformatted disk and this task:

"Format the floppy disk."

You’d be likely to see users scanning the help system for the word "format." However, you would have no idea whether users would naturally think of the task in these terms.

You might try phrasing the task with a synonym that avoids the language used in the help (for example, "Initialize the floppy disk.") Here you would simply see users scanning for the "wrong" word. You'd still get little information about users' natural goal and task representations.

A better approach would be to simply describe the goal state. For example:

"Make it so that the disk is ready for use."

In this case, even though the goal has been presented, users would still need to form their own representation of the task, as in, "Oh, I guess I need to format it."

An even better approach would be to hide the goal altogether within the context of some other task. For example:

"Copy a file onto the floppy disk."

In this case, users must form the goal of formatting the disk entirely on their own, based on cues given to them by the interface.

In testing the online help system for the Mac OS, we relied heavily on these kinds of "booby trapped" tasks. For example:

"Copy a file onto the floppy disk."
(The disk was locked.)

"Play a song from an audio CD."
(The system's audio was set to "mute.")

"Correct the spelling error in this document."
(The document was so large that you couldn't open it without assigning more memory to the word-processor application.)

This style of task design gave us the opportunity to see users forming goals on their own within the context of a lab study. It allowed us to carry our goal-oriented methodology through the entire design process -- from our up-front investigation and analysis, to the design of the system, all the way through to the evaluation of the system.