Journals by RSS
Journals by EmailWe’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.
Related entries (auto-generated):
Already Getting Distanced from Some Project Teams
Well-Phrased Links Help Both Users and Technical Communicators
Establishing the Correct Name of a Project
Project: Reasons for Technical Communicators
Four More Reasons Your Company Needs Technical Communicators
5 Comments to 'Technical Communicators as a Point of Contact between Users and Project Teams'
May 24, 2008
Ben, we are taking much the same approach to two-way communication as you. I want an easy way for users to influence the content, but I also want content that meets professional standards. So I asked a developer to throw together a javascript snippet that would read the title of the page it’s on, convert it to a wiki URL on our site, and print a link to that URL on the bottom of the page. (The link text is something like “Talk back to us.”) Ideally, if enough users hit that link, on enough pages a parallel help system could take shape containing only the pages where users have had questions or contributions. We’ll see how that works when we roll it out next month.
[Reply]
May 24, 2008
Oops — case in point. Misplaced comma turns sentence to gibberish. I meant to put a comma after “on enough pages” and not after “users hit that link.”
[Reply]
May 25, 2008
Ben, I usually check your blog/website every once in a while, because I really like the topics that you write about.
Interestingly, at work, I have been given a task by my Manager to research for methods to incorporate webforms or comments box (similar to this one I am using to write this message) in our webhelp so that the users (mostly internal) can provide feedback on the online help.
Initial thoughts are to either publish the comments (after validating them) in a feedback file for others to have a look at or store them in a database and collate them for our Tech Writing team to understand “what the users really want”.
It might be a little while before this happens, but just thought you might want to comment on this?
[Reply]
May 27, 2008
I think it’s a great idea. My personal concept would be to remove the comment once I incorporate the feedback. I would probably post a comment explaining why I wasn’t incorporating some feedback if that’s the case. But this is with the idea that the feedback appears on the page, such as with one of these posts. In other words, if the comments aren’t immediately (or later) shown with the help that is being commented on, then you may not need to reply. If you don’t use the feedback file method, will there be some way for users to know that their feedback has been submitted, such as a success message (on submit) or a reply from you?
One tricky thing is drawing the line between feedback on the help and feedback on the product. User feedback sometimes blurs the lines, so what they think is feedback on help is actually feedback on the product. I hope that the engineers are open to that kind of feedback once you sift it out.
[Reply]
May 27, 2008
Ted, you must do what I do in things like emails and instant messaging—reread the text after posting or sending. Thanks for the comment (and the correction).
Please comment here again on the progress of your wiki as it goes forward.
[Reply]
Set Me Straight. Leave a Comment.