Not all feedback is equal—what to include and what to ignore

/, Writing/Not all feedback is equal—what to include and what to ignore

Not all feedback is equal—what to include and what to ignore

Quite a while back, we had a client who wanted a large document structurally edited and turned into plainer English. They’d already had the original content through several rounds of feedback, and had a graphic designer lay it out in Indesign.

And then they realised it wasn’t a very good document.

We were sent the PDF, plus acres of emails with feedback from many, many different people. Sure, we said. No problem, we said.

We summarised all the feedback into a table containing references to page numbers and sections, sent it back to the project manager, then had a teleconference to talk through which changes we would incorporate. Some were directly contradictory, so we talked through this and decided which feedback we would include. Then Minnie and I sat down and rewrote and restructured the document. It was a huge improvement, objectively—measured through a great reduction in word count and a much better readability score—and subjectively, as assessed by us, and the majority of stakeholders.

But some people had further feedback. So, we set up an epic 2-hour teleconference with something like 18 people in multiple locations.

We got through 10 pages of a 35-page document.

Most people were quite pragmatic, and would happily come to a consensus. Others less so.

One person in particular took up a lot of time with rambling non-specific complaints. Well, more or less the same complaint, brought up repeatedly.

‘I just thought it had a more friendly, conversational tone before…’

‘Oh, ok. Here’s the original document, can you show me some examples of what you mean?’

But she couldn’t.

We’d actually taken out a heap of bureaucratic nonsense, and replaced it with some more direct, friendly language. As most other people noted.

This lady was getting caught up on the fact that the document was previously laid out as a designed document with pull quotes and pictures. She’d fallen victim to the halo effect. (And I don’t think she’d read either version in entirety.)

So, then I flew down to Sydney for a meeting in person, where we got through most of the rest of the document. I made the requested changes, and sent the document in.

And then the project manager sent the document out for another round of feedback… It may be out there still.

How do you stop this happening?

For starters, there are some key things to understand:

  • You will never please everyone.
  • A document can’t be all things to all people.

The ‘middle-ground’ position is a logical fallacy. That is, thinking that the correct answer is somewhere between 2 opposing points of view is fundamentally wrong. As the saying goes: A camel is a horse designed by a committee.

(Look, camels are cool and all that…)

While you should incorporate valid stakeholder feedback, you also need to set boundaries around what you’re asking for and how it should be provided.

How to ask for and evaluate feedback

This should tie directly in to the document’s reason for being: Who is the audience, and what should they know or be able to do upon reading it? This affects not just the tone of the language you use, but also what you include and what you don’t.

When you put out the call for feedback, provide this context. Sometimes you need to go further and explicitly state who it isn’t for, or what it shouldn’t do.

Let people know that this is their chance. No late feedback. No second rounds. Let them know you’re not asking for editorial advice (unless you are…), but rather for substantive feedback on the contents of the document.

If you’re asking for feedback from many people, ask them to provide it in a stand-alone email or document, not as tracked—or even worse, not-tracked!—changes in the original document. Trying to compile feedback from 20 versions of a document isn’t fun—especially when people may have edited the same parts in conflicting ways.

Once you have your feedback, compile it all in a table so you can see relevant comments side by side. Evaluate these comments in the context of the document’s purpose. Generally, ignore anything that doesn’t meet these criteria. Mark comments as ones to include, ones to ignore, and ones that may need resolution or further discussion. Sometimes you may need to call an important stakeholder and talk through or clarify their feedback—frequently, they’ll be happy to retract it if they understand it doesn’t support the purpose of the document. If you need to, discuss anything contentious with someone whose opinion you trust, or a small group of reliable stakeholders. Where necessary, make captain’s calls.

Finish the damn document. Stop putting it out for endless rounds of feedback.

A recipe is not necessarily improved by adding more ingredients. A song isn’t always made better by adding more instruments. Incorporating more and more feedback in a document goes past the point of diminishing returns—more likely, it makes the document longer, less cohesive, and worse…

Get it out there. Let people use it, and, if necessary, update it in future versions.

By |2018-08-27T13:43:56+00:00August 27th, 2018|Editing, Writing|0 Comments

About the Author:

Writer, editor, musician, plain English evangelist, content ninja for hire, and general web guy, Rory does lots of things, when he has time...

Comment on this post