Categories

Users Online

+ 24 Guests + 4 Bots

7 Principles of Effective Critique in Technical Communications

© 2010 Ugur Akinci

Critique is an important tool to improve technical communications. Yet improper and ineffective critique is worse than no critique at all since it alienates the receivers and puts them in a defensive mood. From that point on all efforts for improvement will be futile and fruitless.

So here are the 7 principles of effective critique that all instructors and mentors should adhere to:

  1. Objective
  2. Specific
  3. Constructive
  4. Comprehensive
  5. Acceptable
  6. Flexible
  7. Organized

1. OBJECTIVE — Limit your critique to the observed behavior of the student and do not criticize her personality, general psychological traits, or (even worse!) physical characteristics. Don’t allow your personal feelings color your statements. Be kind, but honest. Select your words carefully and say what needs to be said with minimum emotions and without hurting the feelings of the receiver.

2. SPECIFIC — A student cannot understand an error and correct it if the instructor is not specific enough. For example, to say “your document is not good” means nothing to a student since the statement has no clues about correcting the situation. However, a specific statement like the following also offers its own solution: “You should’ve used a sans-serif font for your Header1 titles.”

3. CONSTRUCTIVE — Our world is awash in negativity. There is no point in being destructive when identifying a mistake. But, flattering someone just to make them good has no educational value either. So try to give support for the student’s true strengths in your criticism while presenting the negative aspects as “issues that are open to improvement.” Carefully selected euphemisms (like using the phrase “room for improvement” instead of “that’s awful!”) go a long way in this context.

4. COMPREHENSIVE – Your critique should be balanced and include both good and bad points of the student. It should not leave out any important points while prioritizing the solution steps. For example, there’s no point in telling someone to come up with a better DTD if the person does not even know the first thing about XML and structured authoring. Or if a student uses poetic language in a user’s manual, one should praise the student’s imagination and creative writing skills while gently steering him towards a less-flowery and disciplined writing style.

5. ACCEPTABLE — The instructor must be perceived as a legitimate authority before the critique can be accepted by the student. When there are questions about the authority, knowledge, or fairness of the instructor, the critique will fall on deaf ears no mater how qualified and well-intentioned it might be. If that common ground of respect and acceptance is not established beforehand, no critique will be useful.

6. FLEXIBLE — An instructor should be able to shape his critique depending on the audience, context, etc. For example, in a classroom setting, students may be in a different mood from day to day. You must be flexible enough to take into consideration such human factors as well as the background, expectations and prior training of the audience.

7. ORGANIZED — A good instructor takes the student by the hand and leads her through as few steps as possible to the desired goal of the instruction or the critique session. Breaking a performance failure into smaller parts and focusing on how to improve each part in logical order works well in most situations. For example, if a student cannot compile a help file from a FrameMaker book, one might go back to the way the FM book is structured, which paragraph styles are defined, and how they are mapped to the help file styles, etc. Once that is done, one might next focus on any possible software or hardware malfunction, etc. Flowcharts, tables and process diagrams are useful reference materials to communicate an organized critique.

Share

Leave a Reply

  

  

  


*

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>