|May 2005 issue (Vol 11, No. 4)
About the Author
Jaya Parameswaran is the Manager, Documentation, at SISL Healthcare.
He is a member of the India Chapter
This article first appeared in the July 2004 issue of Indus.
Managing Customer Feedback on User Documentation
By Jaya Parameswaran
Being very close to a recently formed writers’ task force that plans to solicit, compile and act upon customer feedback, this topic is timely and in good context for me. We have just stepped out of the teething phase!
Why feedback? Significant reasons!
Product management offices (PMOs) maintain that documentation should meet problem solving requirements and customer preferences to the maximum while keeping customer support to the minimum—for reasons of profitability.
Legal procedures underline that products and services must be supported by sufficient information to help all families of customers safely benefit from their use.
Usability-analyses by expert agencies bring in such a wealth of feedback that they have become a regular prescription for positive change. Lastly, because the lines between the customer and a PMO are so open for communication, we have learnt not to avoid feedback but to use it as a mechanism for continuous improvement.
Good questions to ask
Answers will depend on the product, and the corporate that takes it to market. To keep within the context of our newsletter let us get straight to the point and talk about customer feedback, with respect to software-product-documentation.
Answers to questions
Familiar answers? If quite a few of us agree, it means, we have reckoned with this important aspect of continuous improvement. Lucky ones among us would also have records of how they dealt with sticky issues related to customer feedback.
Any product documentation
With India IT inc. catering to a range of products, we have in our midst, people who create:
Naturally we have writers who create technical documentation to support all of these genres in the worldwide market. And make no mistake, without exception, any product in these classes, has customers quite often looking out (desperately?) for the documentation.
Customer is king!
For every product, a typical IT solution corporation ensures that its documentation department* creates the required publications: release note, installation guide, online help packaged with the solution’s software and the on-the-job-user’s guide. The last named can have various titles—post-installation guide, operations guide, user’s manual or configuration manual depending on the usage area it addresses.
The corporate simultaneously nurtures a group to hand-hold and help users get accustomed to the workings of the product. If that sums up customer support for management think-tanks, it is also a first step in the cycle that the title of our topic signifies.
* Although this is typical, there are titles such as User education, product information, etc.; there is not much in a name really specially in this case.
The change request mechanism
Despite the ubiquitous customer feedback forms, inputs reach the PMO mostly through the trouble-ticket or change request mechanism. IT corporations, either use a proprietary process, or tweak off-the-shelf programs for tracking customer feedback. Familiar names such as IPMT, Sea-Pine, ChaRMnt, aim to help customers post their input and set a priority label (P1, P2, P3…) to let the product office understand how important their feedback is.
Act on priority?
No feedback mechanism
Lone writers and small groups of writers with frequent release deadlines can face this situation. A review policy involving peer-developers, testers and writers is highly recommended in such cases. While the reviews can be informally established, review input must be treated with utmost respect. The peer is king/queen. His or her input must be carefully considered before acceptance or rejection. Sufficient reasoning should qualify a rejected comment. Such a policy if well sustained, can lead to a great product documentation setup and one of immense learning for all concerned, but most importantly, it can lead to precise and correct technical content delivered to the waiting customer – anywhere.
First time perfect
Take for instance a basic product developed in Bangalore, for customization in Taiwan, to address three diverse international markets: Japan, Europe, and Australia. The SDK (software development kit) documentation would be crucial here. The engineer there will depend on you (the writer) to spell out a bible when it comes to installing the kit and using the programming interfaces as expeditiously as possible. Incorrect instructions and erroneous code samples will waste his time. A timely peer-tester review would have flagged errors, latest updates and current procedures. Incorporating all of those will ensure that the SDK is nothing but current. Any documentation group will have to deal with the fact that customer feedback in such cases might be a bit too late to act upon!
Customer feedback versus expert opinion
Quite a few among us would have had to deal with two (or more) key commentators talking at cross-purposes when they complain that a third party product which has to blend with our enterprise product, does not behave as described in the documentation. The writer – quite rightly reads through the bug report from all senders, to discover that they are stating two opposites. The best way to tackle this would be to get the domain expert’s comment. If senders of the error report are not satisfied with the writer’s correction based on expert advice, they can interact with the expert and the application via a walkthrough or net-conference, until all are in agreement that the report is no longer a record against product documentation.
This much and no more?
In case of rapidly changing products, even enthusiasm-driven writers grumble that documentation supports the product endlessly based on customer feedback. Should we draw a line somewhere? The answer should be “no”. Technical publications must be as current as the latest version of the product.
The feeling of “endless” support is usually only during the early phases of a product’s acceptance in its niche. As a support task group, the documentation
Have you had a beaming support engineer tell you about the customer who managed a difficult utility (in a product) with relative ease, depending on nothing but the product’s documentation? If yes, you have reached a point from where you can only get better. Such feedback tells us that we have come to terms with the art and technique of precise and correct technical communication!
Customer-feedback concerning product documentation is an “artifact” of value. Product/project management depends on documentation groups to play an active role in closing the feedback acceptance and incorporation cycle to the best satisfaction of the sending-customer. When we( in documentation groups) internalize this practice, we can be sure to reach our motto of helping the distant customers help themselves - with the least noise.
|All articles are property of the author or publication providing reprint permission. Reprinting this content in part or in whole requires permission from the source.|