“I’m not sure. There are things I would change and things I would keep the same.”

This statement is the winner of my imaginary Worst Feedback Award. After being pestered by me and everyone I could recruit for weeks, that statement was all my subject matter expert could muster. For designers and developers, feedback is a lifeline. For subject matter experts, it’s their opportunity get a derailed train back on the tracks or, in some cases, simply to be heard. We all know how vital feedback is to our process, but few practitioners have a formalized the process of collecting feedback or preparing reviewers to write it.

Collecting feedback is inherent to everyone’s quality control process. In fact, many quality control processes consist only of collecting and implementing feedback. Many of us have tried the newer feedback tools that have come and gone, but in my experience as a freelancer moving from company to company, Microsoft Excel and Google Sheets are the tools I see used most frequently. Tools are a problem to solve another day; but regardless of which tool you use, how subject matter experts write their feedback can enhance any feedback process.

Feedback needs to be as specific and succinct as possible. Here is a formula that works with the table I use: Reviewers must first identify the type of feedback they are entering and the location of the issue, and then construct a feedback statement using provided guidelines. Let’s start with type.

Type

There are several types of feedback in regular document reviews, such as noting text typos, visual issues, and general recommendations.

• A typo is a text-based error or mistake.

• Visual errors include blurry, disproportionately shaped images (for example, stretched images, poor resolution, sloppy cropping, or color problems). This does not include commentary on image choice or the appearance of the people in the images.

• Navigation errors include dead links, missing buttons, and other instances of unintuitive site navigation.

• Consistency issues are not necessarily errors; they are items that seem similar having dissimilar attributes or functionality.

• A recommendation is subjective feedback on anything in the course.

• Other is for those items that do not fit neatly in a category.

Location

Whether a reviewer can specify the correct location depends on the developer’s strategy for identifying locations. For example, regardless of whether the final version of your course includes a menu with numbered items, you may want to include one in your course throughout the review process. Consider titling your screens and layers so that if the reviewer becomes unsure of where they are, they can use the slide title instead.

You may want to provide examples so that reviewers know how to indicate where each item is located. Here’s one example:

Formula: \[Screen number\]; \[Screen location\]; \[Object\]

Example: Screen 12.1; notes; para 1

The Feedback Statement

I encourage my reviewers to construct feedback statements according to a process. I know what you may be thinking—feedback is often too complex for any blueprint. Any quality control process you create must be flexible; in those times when the feedback is complex, do not use the structure. But I bet the vast majority of feedback will fit nicely into one concise statement. Now you may be thinking, “My reviewers will never go for this.” Many won’t; but I have found that reviewers want guidance. The reason their feedback may be so convoluted is because they don’t know how to articulate their statements the way “we want it.”

Here’s the feedback statement template I use:

\[Action verb\] \[current state\] \[correct or recommended state\] \[location, if necessary\] \[explanation, if necessary\]

Example:

Change “…the managers feedback is essential…” to “…the manager’s feedback is essential…” on the slide in the second paragraph.

Guidelines

Use ellipsis to indicate that the change is part of a sentence. Use front ellipsis to indicate that there are words that precede the text in the same sentence and use back ellipsis to indicate that there are words after it in the same sentence.

• Use quotation marks around the targeted words.

• For e-learning or slide presentations, indicate whether the change is in the notes or on the slide.

• Always start with the verb that describes the action you are recommending the developer take. It may be preferable to use the verb “Review” if you only want to bring an item to the developer’s attention instead of encouraging a change.

• Get straight to the point. Do not begin feedback with statements like, “There is a typo on this slide…” or “The learner may find this confusing because…” Begin with the action that the developer must take. Put explanation at the end.

• Provide rationales for recommendations often as possible—the other types most likely do not need rationales. For example, if you’re reporting a simple typo, there’s no need to write, “Change ‘a’ to ‘an’ on the slide in the second bullet point because the word ‘an’ is followed by a word that begins with a vowel sound.” However, if you recommend that the developer delete “correctly” from the phrase “Enter your username and password correctly,” you should explain why you’re recommending the change because your rationale may not be obvious. Write, “Delete ‘…correctly’ from the phrase ‘Enter your username and password correctly’ because it’s common knowledge that usernames and passwords should be entered correctly.”

It’s perhaps time for our industry to take a closer look at formalizing our quality assurance and control processes. Few organizations have staff dedicated to the quality process. But until we can get to that point, developing guidelines for the processes we use now is a step in the right direction.

Want to learn more? Join me at ATD 2018 for my session, What’s Wrong With This Course? Quality Testing and Editing Strategies for Designers and Developers.