Ross Esmond

Code, Prose, and Mathematics.

portrait of myself, Ross Esmond

Constructive Criticism

Constructive Criticism is actionable and inoffensive. Achieving these two objectives may be performed with largely overlapping strategies, as criticism that is actionable is less frustrating, and criticism that is inoffensive will be easier for the recipient to act upon. Constructive Criticism, most importantly, must focus on a specific problem, rather than a proposed solution. Providing a proposed solution strips the recipient of the agency to select their own, whereas identifying a specific issue without proposing a solution acknowledges that the recipient is capable of solving the problem on their own. The recipient will often have a better claim to select a solution than yourself. Otherwise, why would you be providing your feedback to this person. Once an issue has been described, a potential solution may be presented, but it should only be presented as a demand if you are in a position to do so, though it should almost always be presented as a suggestion, and nothing more.

Once a problem has been identified, it must be presented carefully, so as to avoid offense. In many situations, the words “I feel” may help to alleviate tension, but it is not always appropriate to use. “I feel this text violates the WCAG contrast requirements for small text” sounds like you’re coddling the recipient since the statement is too objective for the “I feel” qualifier. Instead of defaulting to conflict-avoidance terms, you should carefully select your words based on three criteria.

  • How sure are you that this is an issue?
  • How likely is this issue to affect people besides yourself?
  • How much involvement did the recipient have in producing the issue?

If you are certain that there is an issue, as with the text contrast example, then you should say so plainly. “This text is too light on the blue background, and breaks the WCAG contrast requirements.” If you are less certain—for example, if it only appears to you that the text might not be dark enough—then you should present your feedback as such. “This text is a little hard to make out on the blue background. It might break the WCAG contrast requirements.”

Often you will find yourself criticizing an issue that might not affect people besides yourself, at which point it becomes appropriate to use the “I feel” style of statement, though there are many varieties. This statement should always be used to express that the issue may not apply to others, and often goes hand in hand with how sure you are about the issue. “I find it hard to tell these icons apart” is a more appropriate statement than “these icons are difficult to tell apart,” as you might be alone in this criticism.

Finally, how much involvement the recipient had in creating or missing the issue can be worked into the statement, if it is known to you at the time, in order to preempt defensiveness whenever the recipient is free from blame. If the recipient did not write the design system that resulted in grey text on a blue background, you should work to pin blame on the design system to express your understanding that the recipient is innocent in regards to the problem. “It looks like our design system makes the text too light for the blue background.” If the recipient is to blame for the issue, then you should still blame inanimate systems in your language, though the target of blame may be less specific. “This text is too light on the blue background” avoids an accusation toward anyone or anything besides the issue itself. When the recipient happens to be culpable in producing the issue, it becomes especially important to be precise in how sure you are about the issue, as you want to avoid an accusation that is unfounded.

Another important consideration, besides phrasing, is the timing that the criticism should be given, especially in regards to the audience who witnesses said criticism. As a rule, criticism should never be given at the same time that you realize you would like to give it. You should always wait to select an optimal time, even if it is just a few moments later. Before deciding to actually provide the feedback, you should ask yourself

  • Will the criticism embarrass the recipient in front of the audience more than I intend to?
  • Will I make the audience uncomfortable with my criticism?
  • Is there someone else in the room whose feedback is more important than my own?
  • Am I wasting the audience’s time by providing the feedback now rather than finding the recipient alone?
  • Will this criticism throw the recipient “off their game,” such that it would be better to wait until they are no longer actively presenting?
  • Is the recipient trying to communicate something to the audience, such that I would be interrupting that process?
  • Is it possible the recipient is about to provide some information that will render my feedback irrelevant?

Quite often you will find that the criticism should be given much later, with far less of an audience, with the most common exception being presentations where the purpose is to collect feedback. Even then, you should wait until the presenter asks for the feedback, in order to avoid interrupting their thoughts in the middle of a presentation.