Selling from the Reader's Point of View, Or Whipping up enthusiasm

Unfortunately, when technical writers or instructional designers talk about their documents or courses, they often do it from the point of view of someone who has read the document or taken the course. Often this turns into the point of view of someone interested in improving their knowledge of the field rather than the point of view of a practitioner: someone interested doing something useful in the field.

This matters for an important reasons: The description of your document/course often controls who many people actually ever read it or take it. Very few people read technical documents or take technical courses for fun. Most readers/participants are there because they need help. At the very least, then, when describing a technical document or course, the author should try to whip up some enthusiasm for the material covered.

Now this may sound like I'm suggesting some kind of phoney marketing ploy but that's not my intent. The surest away to encourage interest in a technical document or course is to talk about what interests the potential participant or reader--remembering that the audience for this description hasn't yet read the document or taken the course. You need to describe your document or course in terms of what it will enable the reader/participant to do that they weren't able to do (or do as well) before.

In other words, a description of a technical document or course should be a description that talks about what the audience wants to know, of what keeps the audience awake at night, of what will have value for the audience.

I saw this recently in a brochure page describing a Learning Tree course. The author of the brochure showed admirable restraint, appropriate for someone already part of the field and secure in the field's knowledge. However, the bullet points that described the course objectives seemed specifically designed not to connect with the audience. For instance, the first bullet was:

• Perform key functions of the business analyst by applying a solid business analysis framework

I find it difficult to believe that anyone wakes up in the morning thinking "Gee, I wish I could perform the key functions of the business analyst" or lies awake at night worrying that they don't have "a solid business analysis framework." People worry about very specific things, not generalized issues like "key functions" or want generalized help like "solid framework."

In fact, this is a bullet that's interesting only to someone who already knows that the key functions in the field are and, while they have some skills in the area, want to solidify their knowledge into some kind of structured knowledge. These are the goals of someone primarily interested in improving their knowledge of the field (solidifying, getting a framework), not in doing a better job at work ("performing"--a very general term--references the even more nebulous "key functions").

So, what do potential readers/participants care about? This particular course was aimed at business analysts who are expected to determine the current and potential problems for an organization, define a list of potential solutions, help the organization pick a solution from that list, and then support implementing the chosen solution (which might be an amalgam of some of the proposed solutions).

The first thing that a potential business analyst would worry about, then, is their ability to identify the organization's problems. If the analyst gets that wrong, all the subsequent work is misdirected and, when the "real" problems turn up, the organization will be unprepared. So a bullet that would describe a course that's interesting to someone who doesn't already know the material would be something like this:

• Perform a key function of the business analyst: Identify the organization’s key problems

This is, of course, just a first cut (I'd love to replace the generic "Perform" and "Identify" verbs with something more specific). But, I imagine, it would be something that potential reader/participant would read and say "Yes! I want to know that! I need to know that."




Reading or Read

• Speak by Laurie Halse Anderson
• Changeover by Margaret Mahy
• Gathering Blue by Lois Lowry
• The Monk by Matthew Lewis
• Road to Brightcity by Máirtin Ó Cadhain 
• Canon Alberic's Scrap-Book by M R James
• The History of Science Fiction by Adam Roberts
• The Fifty Minute Mermaid by Nuala Ni Dhomhnaill and Paul Muldoon
• Myth, Legend, and Romance: An Encyclopaedia of Irish Folk Tradition by Dáithí Ó hÓgáin
• Doctor Copernicus by John Banville