Getting good feedback is one of the hardest problems in technical writing.
Compared to programming, getting feedback on documentation is slow. I can run a test suite on my code every minute if I want to, but I have to find a real, live human to read over my documentation, every time. And even if I can wring some feedback out of somebody, I’m often surprised by what it is I get.
Some feedback gives me insight and motivation, while some feedback doesn’t. To make sense of the surprises, I try to evaluate the feedback I receive in relationship to the meaningful change it does or does not support. Then I can choose whether to embrace, reject, defer, or ignore it.
Thus, the feedback matrix:
|Significant||Quadrant I||Quadrant II|
|Trivial||Quadrant III||Quadrant IV|
The columns represent usefulness, whether the feedback can be acted upon to make actual change to the outcome of a project. Feedback is useless when it cannot be acted upon. Feedback is actionable when doing something doesn’t run afoul of some constraint, like project scope, legal requirements, or some aesthetic principle.
The rows represent significance, whether the feedback concerns some necessary, important, or memorable aspect of a project. Feedback is insignificant, or trivial, when it concerns portions of a project that are little valued, low visibility, or inconsequential.
So, placed on both axes, feedback can be assessed as falling into one of the four quadrants:
Useless and trivial feedback cannot or should not be acted upon, but wouldn’t matter even if it were. Useless and trivial is the one-star review that only says, “this sucks.” Acting on such feedback would not change any outcomes.
For example, suppose you received a reader’s comment objecting to the use of the serial comma in a situation where the usage does not change the clarity of the sentence. The use of the serial comma is required by your style guide and, if you changed your usage, would result in contradictory feedback from other readers.
Response: Ignore. Politely, of course.
Useful but trivial feedback can be acted upon, but it’s low priority work. It’s the kind of thing you can fix in a few spare minutes before a meeting. For example, a colleague reports to you that a word is italicized when it ought to be bold. No one’s going to be confused by the error, but you should fix it, if only as a matter of professional pride.
Response: Defer. It’s nice to have a backlog of such feedback with which to break writer’s block.
Significant, but useless feedback concerns important issues, but cannot be acted upon. Such feedback addresses real, identifiable areas for improvement, which are, for whatever reason, out of reach. The solution is out of your scope, beyond your pay grade, or would require more effort than your lifespan would tolerate.
For example, an advance reader discovers a bug in the sample code of your book after it has gone to press. Despite your best efforts, the publisher is unwilling to recall the books. The project is over and there is nothing to be done.
Response: Reject. Don’t get mired in such issues, or else you may find yourself spending considerable energy to no appreciable effect. But keep a note of the feedback, as you might get a second chance someday, or at least a second edition.
Significant and useful feedback is the kind of feedback worth living for. Such feedback concerns important matters without being lofty. You can begin to act on this feedback today, with a meaningful improvement to your project’s outcome. For example, a reader makes you aware of a use case for your application that your documentation does not cover, but the use case is behind a considerable portion of the application’s revenue.
Response: Embrace and act, immediately, if at all possible. If someone gives you this kind of feedback more than once, make friends or enemies with them as appropriate, so you’ll never want for such feedback again.