My good friend, Ben Minson at beyond-help.net, posted some thoughts he had on a topic rating system that his team used for their documentation (see his post here). In his post, Ben described that his team was using a very simple rating system on their pages — did this topic help you, or not? His team found the results from this little survey so useless that they eventually removed it from their site.
On that same note, I was working with a client recently whose company delivered only PDF manuals for their documentation. In the front matter for her books, she included an invitation for her readers to send comments on the documentation. She said that in 16 years, she’s never once received a comment.
When I worked at IBM, in addition to a comment address, we included an actual comment postcard in the printed manuals that customers could cut out, write on, and send in to us. In my six years on that team, no customer ever took the time to send us a comment using the hardcopy methods (we did receive electronic comments from time-to-time.)
There seems to be a conundrum when it comes to gathering good feedback from users. Nobody really likes sending feedback, and as a result, we try to make sending feedback as painless as possible for users — so painless, in fact, that the feedback can actually be worthless, like the situation that Ben described. How do we bridge this gap?
Because getting feedback from users seems to be so futile, we’ve instead relied on things like Google Analytics or Adobe Site Catalyst to try to back our way into getting an understanding of whether our users are using our documentation, and if so, whether they find it helpful. But still, we can collect mountains of data, and in spite of analyzing it to the moon and back, we still most likely won’t get an answer to these simple questions:
- Did you find the information that addressed your problem?
- Did that information, in fact, help you solve your problem?
- What can we do to improve it?
- If the topic didn’t help, what resources did you use to get your problem addressed?
I don’t have any good answers, but I have a couple of thoughts on what might help.
Engage the support organization
I worked as a project manager in a support organization for a few years, and if a support organization is anything, it’s a giant customer comment receptacle. As a result of this, does it make sense, from an organizational perspective, to align the documentation team with the support team? Teams tend to align documentation with product development. While I fully agree that doc development is part of product development, the development team doesn’t have their finger on the customers’ pulse like support does.
Make the user help experience more social
I think we need to try to break the mold of just dishing information out to our customers. Social media is here to stay. How do we leverage social media concepts to structure a user help experience that engages our users? I’m in the process of setting up a MadCap Pulse server in my basement, so I’m eager to see how it works. What experiences do others have?
Clearly, as Ben mentioned in his post, we need to move beyond the simple yes-or-no feedback methods if we are going to hit the gold mine of customer feedback. What thoughts and experiences do you have?