We’ve been taking a step back and examining our documentation approach at work. It’s easy, and there is still time to change things, because our team is small. We’re not set in our ways, and we haven’t had an approach or tools dictated to us. One of the main concerns we have is the big disconnect between users and the project team.

Sure, there are interaction designers and business analysts who gather requirements and translate them into user-friendly and user-desired interfaces. At least they try. Many times, even the key stakeholders’ views don’t coincide exactly with the users’ views. It’s a challenge when you’re trying to meet the needs of users who are scattered across the world.

However, as Tom Johnson has brought to our team’s attention, Web 2.0 offers a way for technical communicators to increase their importance as a point of contact between users and the project team. (He posted recently about his experiments with SharePoint to accomplish this goal.) Now I’m not blowing a trumpet and saying that Web 2.0 is a cure-all for the tech writer’s ailments. But there are advantages to it.

The basic idea of Web 2.0 is contribution to Web content. My preference is that we don’t let users have free rein on a site through a wiki, because I still would like some editorial control. The documentation still needs to look professional and polished. What I’m in favor of is providing users the ability to communicate directly with us in some form of a help site (not just a help system).

One project I’m on that is in a beta test stage right now provides a feedback mechanism in the application. Some of the emails we’ve received show the users’ perception that they’re yelling, but no one’s answering. They’re like the caveman from the late Johnny Hart’s B.C. comic strip—sending off a message across the sea and waiting eagerly for a reply… but in their case, the reply drifts back only once in a while.

That’s being fixed by our stakeholder department, but we can do better. If we provide a place for users to see each others’ feedback, they can chime in together on important issues. They can spark ideas in each others’ minds. The stakeholder department will make decisions about what feedback will be incorporated into development, but it’s important at a basic level for users to feel like they’re heard.

A lot of people are busy, and they probably spend enough time working in the application that they don’t want to take more time to participate in a community. But I anticipate that if the ability to communicate is there in a help site, some people will try it out. And when they see someone—the technical communicator—answering them, they’ll feel more inclined to participate.

Many details remain to be explored. We’re looking at the technologies that would allow us to do this, but there are also process questions. How much support will the stakeholders provide through their department? How much of the burden is on our department? How do we keep from being sucked into support and have our jobs drift away from documentation and training?

I think a moderate approach to documentation and Web 2.0 will bring many advantages and many challenges. But one way that it can benefit the technical communicator is to put him or her in an important position as one who knows what the users want. Someone with a close relationship to the user in a development team is a rare thing because of the black holes in which we usually work—and rare things are valuable.