Vesa Purho
Development Manager, Nokia

How many times have you wondered that if you could just get feedback and requirements from your customers, you would know how to improve your documentation? You may have even attached forms to your documents and allowed the customers to send you feedback through your Web site. Have they worked? My bet is that they haven’t, and even if you have received feedback, how do you know that the other users think the same? The only way to get requirements for your documentation is to go and get them.

Why don’t the passive feedback collection methods work? Think about how you act in a situation where you have bought a piece of equipment, and the documentation is terrible. How many times have you bothered to find out if there is contact information in the documentation or if you can send feedback through the manufacturer’s Web site? Personally, I have never done so, even though I’m in the business of creating documentation and know how much I like to get feedback. What is the reason for this behaviour? I don’t have all of the answers as I’m not a psychologist; however, part of it comes down to the fact that I have already purchased the product and my complaining is not going to help me, so why bother? People, by nature, are lazy and seek instant gratification. If I complain now, then perhaps those buying the next model from the company will see the improvement, but what’s in it for me?

If you want to get feedback, you have to be active to get it. There are several ways of getting feedback. Some of these methods involve the users directly, and some methods are more indirect, causing you to get your hands on information that already exists within your company. The Capability Maturity Model Integration (CMMI)(, which is an improved version of the Capability Maturity Model (CMM) by the Software Engineering Institute, has a process area called Requirements Development that deals with how to elicit and develop requirements. Even though the CMMI model does not describe how to implement change as much as it puts requirements on what must be done, the process area description lists the following examples of receiving requirements:

  • Technology demonstrations
  • Interface control working groups
  • Technical control working groups
  • Interim project reviews
  • Questionnaires, interviews, and operational scenarios obtained from end users
  • Operational walk-throughs and end-user task analysis
  • Prototypes and models
  • Brainstorming
  • Quality Function Deployment(
  • Market surveys
  • Beta testing
  • Extraction from sources such as documents, standards, or specifications
  • Observation of existing products, environments, and workflow patterns
  • Use cases
  • Business case analyses
  • Reverse engineering (for legacy products)

Not all of these apply to documentation requirements, but many could be used. None of them says, “Sit and wait for customers to send you feedback.” They all involve the developers actively interviewing, observing, and reading; something that must be done if you want to get requirements for documentation. If you cannot involve customers directly, involve people who deal with customers: support personnel, customer training personnel, those SMEs who fix problems at customer sites, as well as other internal sources of customer and user information. Ask to see the technical support call logs, or even better, sit in technical support for a few days to get an idea of what it is that troubles the users and then determine if you can help them with documentation.

When trying to get requirements, remember that with the same number of resources, you can get either very detailed feedback in one area or very high-level feedback in many areas. My advice is to take it gradually. It is better to concentrate on one area and get to the bottom of what the users really need than to try to improve all areas at once. You may make some improvements, but since the feedback is not that detailed, there are many areas where you may go wrong.

Whatever you do, don’t just sit and wait for user feedback and requirements to come to you. They won’t.

This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.