1. In-House Sources
to Collaborate With
Eileen Pålsson, eileen.palsson@readsoft.com
Support technicians
They know the most common user questions or misconceptions, areas in which documentation is lacking, etc. Can
often point out errors or suggest improvements.
 Meet with Support manager and ask for ideas. Emphasize what’s in it for them (for example fewer Support
cases).
 Some Support departments develop and maintain their own body of documentation. Explain how they would
be better served by working with you to spread the information via the official product documentation, and
referring users to that documentation when appropriate.
 Suggest multiple ways they can provide input and feedback: Email, phone call, stopping by your office,
sending a link to a support case where they think better documentation could have helped.
 If Support technicians are timed or their performance measured, feedback to Tech Comm should somehow
measure in.
 Get mentioned in Support’s online newsletter, blog, etc.
SMEs and Quality Assurance technicians
They possess the most detailed technical knowledge.
 Agile teams have daily stand-ups or scrum meetings. Be vocal about what you’re working on and ask others to
check the work.
 Testing new features must include reviewing the documentation for accuracy and suitability from a user
perspective.
 Review process should include SME review and/or QA “test” of documentation.
Trainers
Trainers know the products – and which areas new users have trouble with.
 Tech writers and trainers collaborate closely for mutual benefit.
 Training material can be a great source of input for overview topics and tips & tricks.
 Tip: Ask trainers to show users the product documentation. If they don’t (or they refuse), find out why.

2. New employees
Newbies are very gung-ho and can point out areas where the documentation is unclear. You can provide an outlet
for their frustrations (which in some respects can be the same as user frustrations).
 Introduce yourself to new employees who will be learning the product. Point out that the documentation is
useful when learning the product.
 Let them know that their comments about the documentation can be valuable to the company in improving the
user experience.
 Provide your contact info and what you’re interested in on a business card.
Translators
Language experts can point out inconsistencies and imprecise explanations.
 Make it known to in-house translators (or the translation agency) that you encourage feedback regarding the
original text.
 Even if this can’t affect the current version (where localization is already in progress), it can have great impact
on future versions.
When you receive input
 Make it pleasant for them. They are helping you.
 Express appreciation for the input. A sincere thank-you goes a long way. Thank them for specific details; for
pointing out an area of missing or unclear information; for their assistance in improving the documentation.
 If it’s going to take awhile to implement the suggestion, let them know it’s on your radar.
 Follow up and let them know when it’s fixed and in which version or release they’ll see the result. If possible,
include a copy of the result, a link to the new help topic, etc.
 Recognize contributors – give them credit somehow, for example by mentioning it as a plus at retrospective
meetings, praising them to their manager, etc.
 Make these things habits. Keep repeating the same consistent message – that you welcome input & feedback.
Additional tips
 Monitor Support channels, FAQs maintained by others, user forums (both internal and external), etc.
 Resort to bribery! Candy! Money! One company offered $200 per help topic that was written by SMEs outside
of work time.
 If you don’t mind interruptions, keep treats in your office and people may be more likely to drop by with
suggestions.