You are here: Articles --> 2005 -->
To build effective paths...
Vous êtes ici : Essais --> 2005 --> To build effective paths...
by Geoff Hart
Previously published as: Hart, G.J. 2005. To build effective paths, determine where your visitors want to go. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/pathfinding.html
In a previous column, I reported the anecdote of an architect who let visitors to a university campus define their own paths across the newly laid grass rather than deciding himself where the paths should go and forcing people to use those predefined paths. Have you ever thought about doing the same thing as a user's advocate? Your audience generally has a better idea of their needs than you do, and a good idea of where they expect to go to satisfy those needs. The design lesson is that paying attention to their behavior facilitates both our jobs and theirs. Unfortunately, as any battle-scarred veteran of the Web can attest, few Web designers have learned that lesson.
The Internet equivalent of watching people wear holes in the sod is using tracking tools known as Web traffic analyzers (one of the better-known tools for this work is WebTrends. These tools track the vital statistics of site visitors: the software they're using, where they're from, how they use your site's links, and what they do once they reach a destination deep within your site. In theory, these statistics let you make informed decisions about optimizing a site to meet the needs of its users.
In practice, it's easy to be buried by the voluminous data provided by these tools, particularly if you don't have a clear idea of what you’re seeking. How do you get that clue? Ask yourself what interesting things a given statistic might tell you about your visitors. This article discusses a few simple types of data that, with a little user's advocate polish, can help you design a site that pays attention to the needs of your audience.
You may suspect that optimizing a Web site for a single browser is a bad idea simply because so many designers do this. You’d be right, because such sites often look wrong or work incorrectly in other browsers—if they even load. The problem's particularly serious if you focus on Internet Explorer (IE, pronounced ayeeee, like a scream of frustration), still arguably the most popular browser for the best of all possible reasons: it comes pre-installed on just about every computer. However, this widespread availability comes at a cost. IE has a reputation as a security nightmare and a promiscuous violator of a wide range of Web standards; its design flaws have created a whole counterculture of anti-lemmings, rushing frantically away from the cliffs to install an ever-increasing host of alternative browsers. In the meantime, those of us who believe that plunging off a cliff with the other lemmings is vastly overrated when it comes to "experience design" find that sites optimized for IE drive us to death threats and strong drink.
That rant notwithstanding, tracking browser use can still reveal interesting things—if we're prepared to ask what those things mean. For example, if many visitors use Lynx or other text-based browsers, they may simply be UNIX geeks or old fogies like me who still remember what a command line looks like. But some may have significant visual or other handicaps that require them to use assistive technologies. If you do have a large population of visitors with special needs, you have a strong justification for producing a version of your site that conforms to the W3C's Web Accessibility Initiative. If you're an STC member, the AccessAbility SIG is a great place to discuss accessible Web sites.
Eliminating multimedia-dependent functionality such as Flash-based navigation, or providing alternatives for those technologies, can also make good sense. For example, while researching this article, I visited the WebTrends site to seek inspiration about statistics that might be meaningful to us word geeks. Unfortunately, all their product demos required MacroMedia's Breeze software, and that part of the site was down for maintenance for most of the day. The moral: HTML pages don't go down for a full day of maintenance unless you've got a major problem on your site, and Breeze offers few advantages (and no compelling ones) over a series of HTML pages when it comes to presenting product features.
Similarly, if you're relying on extensive ActiveX controls (another security nightmare, though fortunately one that doesn't work on my Mac) and Java (a great idea whose time never seems to have arrived), it pays to remember that many experienced users disable these browser features for security reasons. If your site provides no alternatives, you’re going to lose these people. (You’ve already lost me, for example.)
Knowing where visitors are coming from can suggest the services that you should provide. Some traffic analyzers can identify visitors by country or by the language of their Web browser, which provides strong clues about the linguistic breakdown of your audience. At a minimum, if you're attracting large numbers of non-English visitors, you should consider using a simplified form of English or at the least, rewriting phrases and idioms that depend on intimate knowledge of your home culture. Better still, consider supporting this group by creating a localized version of your site.
Similarly, fun though it is to mock AOL and MSN, both are among the largest service providers in the world. If you start seeing large numbers of AOL or MSN addresses among your visitors, it’s time to consider establishing a presence on these networks to supplement your Web site. At a minimum, you should be providing easy links to your site, but it may make sense to establish a particularly user-friendly community on AOL or MSN. Though it may be going too far to state that AOL and MSN users are Net newbies, and not the sharpest bits in the byte, it's certainly true that these services attract a higher proportion of users who aren't as comfortable as we are with computers. How could you make your Web site support these less-sophisticated users?
If you provide online help or reference material for a product on your Web site, pay close attention to which components of this resource are attracting the most visits. These are clearly the parts of your product that pose the most problems for users, and thus, the parts that are in greatest need of a usability makeover. Product developers, being zealous logical positivists, won't take your word that there's a problem unless you can back up this claim with hard data. A huge spike in the number of visits to a specific Web page provides that data. (Either that, or it was slashdotted.)
Of course, if you're not part of the usability team, and have been ruthlessly excluded from its meetings because of your repeated identification of usability problems, you can at least ensure that you aren’t contributing to the problem. Devote most of your effort to producing the perfect content. Spend 80% of your effort solving the 20% of the problems that cause users 80% of their grief and cost your employer 20% of sales.
As these examples illustrate, traffic analyzers can provide useful data, but they don’t explain the data or tell you what to do about it. Thus, you can’t simply form an opinion on what the statistics mean and blindly implement a solution. That's where we technical communicators come in: we're expert tool users, but our most powerful tools are our intelligence and our empathy for our audience. As the tracking tools increase in power, you'll obtain progressively more detailed and useful visitor information. That's great, but data alone is insufficient; you still need human insight into what that data means. To obtain that insight, subject the site to the scrutiny of your user advocates—technical communicators—who provide a much-needed reality check. Only then should you unleash the site on the unsuspecting Web public. Despite the promises of artificial intelligence, the best analysis tool of all is still the one between your ears.
©2004–2013 Geoffrey Hart. All rights reserved