–Geoff-Hart.com:–Editing, Writing, and Translation

—Home —Services —Books —Articles —Resources —Fiction —Contact me —Français

You are here: Resources --> 2001 --> If you build it, they’ll come
Vous êtes ici : Ressources --> 2001 --> If you build it, they’ll come

If you build it, they’ll come

by Geoff Hart

Previously published as: Hart, G. 2001. If you build it, they'll come. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_buildingacommunity.html

Unless you’ve been sleeping in a cave for the past several years, you’ve undoubtedly heard a fair bit about the notion of “communities” on the Internet. “Build a community,” the common wisdom goes, “and they’ll come to your Web site in droves—you’ll need to upgrade your server!” Common wisdom also holds that communities are easy to build: simply create a chat room for real-time conversations, install a bunch of mailto: fields so people can e-mail you, and set up mailing list software such as Listserv, Majordomo, or Lyris so people can exchange information at a more leisurely pace. Voila! Bob’s your uncle.

Unfortunately, the common wisdom is commonly wrong—or at least misleading.

Part of the problem lies in defining the concept of community. Communities are people with a common location, a shared philosophy or heritage, a consensually developed code of conduct that may be supplemented by formal controls (e.g., a moderator), and shared characteristics or interests. (Raycomm’s own techwr-l community serves as a good example.) Communities often consider themselves distinct from other communities based on these factors and based on their unique needs, so forging a community begins with an understanding of each of these aspects of the definition: your Web site provides the common location; the Internet culture’s underlying assumption that you exist to provide something free represents the shared philosophy or heritage; the concept of “netiquette”, which includes notions of privacy and security and mutual respect, serves as the code of conduct; and your site’s content addresses the common needs and interests that bring people to your site.

That’s a good start, but even coherent, homogeneous communities comprise a diversity of individuals. Surfers with cable modems may cheerfully ignore your elaborate animated graphics and constantly changing banner ads, but technopeasants like me, who still make do with 33.6K modems, chafe at having to endure this visual pollution. A student with time to burn can hang out for hours in your chat rooms, hoping to meet someone who can solve today’s problems, but we busy wage slaves simply want to plunder the site quickly and escape with the information we need, and we’re going to call your 800 number if we don’t find that information fast. And the corporate buyer who visits because “nobody ever got fired for buying IBM” has little in common with those of us who visit solely to find out why we shouldn’t switch from IBM to a clonemaker with equally good products.

[A look back from 2005: No longer a wage slave, and with a cable modem, no longer a technopeasant. But the point remains valid.—GH]

So if you create a community around your Web site, look beyond providing the outer semblances of community: design a site that can potentially work the way each of these very different members of the community wants it to work. The ability to customize sites through appropriate software comes not a moment too soon, as witnessed by the growing popularity of “My Yahoo” and the competitors being offered by most major sites and service providers. But don’t stop there! Automated systems won’t approach the ability of human customer-service representatives to respond to the unexpected any time soon, and until they do, you’ll have to figure out how to fake it. In addition to implementing chat rooms for live technical support, this means keeping a close eye on how people are using your Web site and planning to adapt to your audience’s unforseen or changing needs.

More than half a century ago, some unsung architect completed the design for a university campus, but omitted the paved paths between buildings. When the client pointed out this oversight, the architect replied that the choice was intentional: by letting people pick their own pathways through the grass, they’d learn where the walkways should be installed. The approach worked like a charm. The beauty of the approach lies not in its entertainment value as an anecdote, but rather in the elegance of the design principle it reveals. Though the architect could have produced something reasonably functional by making assumptions about the users and imposing a solution that met their perceived needs, he produced something much better by letting the users themselves show him what they actually needed.

Where do technical communicators fit within this type of design process? It’s our ability to act as user advocates that lets us help Web designers to tailor the design to the needs of the users:

We understand that although a Web site provides the common location for a community, location alone provides just the nucleus around which communities gather.
We understand audiences well enough to recognize the Internet’s culture, the cultures of the audiences we’re trying to attract, and how to reconcile the occasionally different needs that arise from these different cultures.
We understand the content of the site, the common needs and interests that attract people to the Web site, and how to reconcile the two.

All these aspects of understanding are well and good, but they’re not sufficient until we put them to work to meet user needs. Listening to our audience creates and builds upon that understanding, but working with them is what turns the site into a community. As in the architecture example, it’s working with the users of a site that lets them show us how to build the community they want rather than imposing a logical solution based primarily on our needs.