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.

STC UUX Community Newsletter
Usability Interface

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

• Is there a genre of products that have to deal more with customer feedback?
• Who qualifies as ‘customer’? Does any input from the customer-quarter qualify for feedback?
• Is there a standard way to deal with customer feedback?
• Are there formal practices by which feedback is recorded, channeled and sent to the documentation group for taking action?

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

• Every piece of software documentation is target for customer feedback.
• Any user in the real-life scenario of the product, with sufficient domain or product expertise, qualifies as customer. He/She can be – the offshore testing engineer who tests the just-released-package, using the installation and configuration guide that you just checked-in!; the designer who customizes firmware in a chip to support a set of country specific features; a process control engineerwho wants to use the guide to create an electronic workflow to replace the currently manual processes; Customer support personnel; Product Analysts; or even the itinerant sales executive due to meet a potential buyer!
• Comments from these users qualify as feedback – which is why the trouble-ticket/bug/ change request database and the tracking tool are for anybody to use without restriction of hierarchy.
• Professionally managed operations have well established feedback tracking systems.  Documentation departments in such places have processes to direct items of feedback to the right owner of technical content. The content owner is responsible for taking the bug report/trouble ticket/change request to its proper conclusion

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:

• Original equipment – hardware and software
• Fundamental software – portions of operating systems, DBMSs, programming workbenches, testware, buildware, office automation, firmware, SDK…and some more of those
• IT solutions for almost every facet of business and industry

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?

• When customer feedback becomes vague or when priority for correction is arbitrary, coordinators help by scanning through sheets of input, resolve vagueness and set realistic priorities. Error correction becomes Priority 1 or Priority 2, wish-list items are managed with an eye on timelines.
• Reports of errors in the installation guide and the configuration guide, and description of functionality in a user guide mismatched with actual performance are high priority (P1). 
• What about irregular format of a paragraph in an online topic? Or a list with inconsistently sized bullets? The correction request would be “cosmetic” (Priority 3).
• Content owners should act fast on Priority 1s. Consult the expert, ensure that the error is corrected and clear the content for use—as soon as possible. They can bypass priority and deal with the Priority 3s also at the earliest—because printed matter must be close to perfect readability.
• Spelling error? Given who we are, an error of this type is inexcusable—every item of documentation should be spell-checked (manually and electronically) before it rolls out.

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
group should be geared mentally and physically to deal with this in a shared manner. Leadership should understandingly, not saddle one writer with the task of keeping documents up-to-date and useful to its customer!

Positive feedback

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!

Summary

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.