We were discussing the biggest challenges in Tech Comm at the last STC Toronto brunch and we all seemed to agree that the difficulty getting feedback on the effectiveness of the content we create is the biggest challenge. The things that really matter in technical communication is whether users can achieve their goals after finding and reading the docs, and whether that makes a difference in whether they buy from you again or speak well of you to their friends and colleagues. These things are incredibly difficult to measure. You are just not there to see them happen, and it is very difficult to separate their effects from the effects of the work that designers, developers, sales people, trainers, field engineers, and support staff do.
Because we have such a hard time getting that feedback, it is particularly important that we get intermediate feedback: feedback on things like accuracy, consistency, coverage, relevance, and appropriate use of language and examples, which we know, on general principle at least, correlate well with customer success. Yet we do not tend to design our documentation systems and processes to generate such feedback.
It is well established that there is a direct relationship between the speed and accuracy of feedback and quality. The more feedback you get and the more promptly you get it, the better work you will do. But tech comm has traditionally relied almost entirely on human feedback from editors, and reviewers.
But human feedback of this sort has two problems. First, it is slow. You might work for weeks on your content before it is submitted for review or editing. Second, human feedback comes with emotions attached.
We had an interesting discussion on Larry Kunz’s blog about the perils of giving feedback to colleagues. Referring to Liane Davey’s post on giving feedback, Larry talks about the need to be ready to receive feedback, as well as needing to be ready to give it professionally. From a psychological point of view this makes complete sense. The problem is, it means feedback will often be delayed, in order that both parties be in the right frame of mind, and delayed feedback means quality and productivity both suffer.
I suggested in that discussion that we should make a distinction between feedback and coaching. Feedback is a necessary part of work. Feedback tells you if what you are doing is working. It can’t be delayed without cost. Coaching is a part of career development. It is used just as much to make the good better as to make the bad acceptable. But it is not apt to be effective unless both parties are in the right frame of mind.
This distinction is clear enough on paper (or whatever should replace that expression today — clear enough in pixels???), but if the only vehicle you have for giving feedback is human to human, how is the emotional impact any different between feedback and coaching?
Mechanical forms of feedback come without judgment or emotion. We can be frustrated by a machine, even humbled by a machine, but we are never embarrassed by a machine. We don’t feel the machine’s pity or contempt. We do not feel that we have sunk in the estimation of the machine. We can accept mechanical feedback with far more equanimity than we accept human feedback.
Equally importantly, we don’t have to wait for the machine to be finished its own work or have some free time in its schedule before it gives us its feedback. We don’t have to do a bunch more work before we get the feedback on our first piece of work. The work will be fresh in our minds when we get the feedback, and whatever lessons it teaches us we can apply to the work we do next.
Finally, the machine is not flustered or annoyed by our request for feedback. It is not anxious to get back to its own work. It is not bored with the task of giving feedback. It is not jealous of us. It did not wake up on the wrong side of the bed this morning. It’s car is not in the shop, its basement is not flooded, and it did not have a fight with its spouse this morning. It has not forgotten all about the code it wrote three months ago. It does not think its job is to be the grammar police. Nor does it think your documentation should be a paean to the brilliance of its design work.
One of the great advantages of structured writing is that it allows us to build mechanical feedback loops into the content development process. It allows us to develop strict topic types the define exactly what information is required on a particular subject. It allows us to verify information between different documents and between documents and external sources. It also allows us to factor out a lot of the petty mechanical things that writers can get wrong so that we don’t have to bug them with feedback about them, which can give them more time to focus on the more important feedback.
If we can take the human element out of all the kinds of feedback that can be generated mechanically, we not only ensure that that feedback is more complete, more accurate, and more timely than human feedback could possibly be, we may also leave both the giver and receiver of coaching more receptive to it, and allow it to focus on the parts of performance that cannot be judged mechanically.
I find your premise to be interesting, but would have been much more satisfied if some examples of state-of-art in such mechanical feedback methods had been explored (or at least mentioned).
Of course, be now, we’re all familiar with mechanical means such as spelling (and grammar) checkers AND with their limitations.
As an example of the later, consider that there’s at least one spelling check “failure” in your text as of my present reading. (If it’s not fun to find on your own, send me an email and I’ll be happy to point it out 🙂
confessing my own spelling check “failures” !!
“be” should be “by”
“later” should be “latter”
Thanks for the comment, Adam.
I fixed one typo. If you can find it, let me know if it was the one you saw. 🙂
Asking for examples if very fair, and matter for future posts.
If the documentation I write does not prompt my readership to comment (product and support, way before the end users), it is already flawed.
Thanks for the comment, Avi.
That is an interesting way of looking at it. Supposing product and support find no flaw? What then would they comment on?
Hello there! Thank you for this article. I was looking for something on getting feedback for content. Just a nitpick but I noticed paragraph 9.
“Equally importantly, we don’t have to wait for the machine to be finished its own work…”
Or should it have been “Equally importantly, we don’t have to wait for the machine to its own work…”?
Thanks for the comment, John.
No, it shouldn’t have been that, but I think there is a word or two missing from your suggestion.
The point I am trying to make in that sentence is that sometimes a human review has their own work to finish before they are willing to review yours. That further delays the feedback you need. Sorry if that was not clear.