‘Who is your audience?’ That is the oft-repeated question asked of fiction and speech writers. But is it asked of technical writers? Rarely. It ought to be, though, because without knowing who the audience of technical manuals, guides, and curriculum is, the material often gets the content completely wrong.

Let me illustrate by telling a personal story. A few years ago, a colleague of mine was given the task of training a group of business analysts in a fairly technical piece of software. Predictably, the class was a disaster. First of all, my colleague wasn’t a trainer, so his ability to deliver the material was compromised from the beginning. Second, the business analysts weren’t especially technical, so they stumbled over the content of the course, failing to grasp the basics of the software, and frustrated that the ‘trainer’ couldn’t explain it in terms they understood.

A number of factors caused the failure, but the most overwhelming one was the course materials didn’t address the correct audience. The customer had insisted on numerous occasions that the business analysts only needed an overview of the software, to become familiar with how it worked, but not the details that only technicians needed to know. We were dangerously close to compromising our relationship with the customer over this one event. I then offered to rewrite the course material to make it appropriate for a business audience.

Over the course of approximately six weeks, I discarded the majority of the existing materials, retaining only some of the explanations of what the software was and did. I eliminated all the practise exercises, creating a single one, instead, that I knew could be completed by non-technical users of the software. I gave a history of the evolution of the software and its reason for being, which proved both interesting and edifying for this particular audience. I then had a colleague (not the same one) read through the entire overview course and point out any errors or inaccuracies. I sent a brief, but detailed, outline to the customer to help regain their trust that we could deliver what they needed.

Next I travelled to Canberra to deliver the course to a first group of business analysts. The response was unanimously positive. They finally grasped the material and they were able to participate in discussions without feeling overwhelmed with technical jargon. I’d also whittled the material down to a day-and-a-half worth of content, as opposed to the three days for the previous version.

The lesson we quickly drew from this painful exercise in customer satisfaction was: don’t assume one view of technical content is suited to all audiences. When we spent the time to assess the customer’s needs, we were able to deliver a course that met and even exceeded their expectations. The relationship was repaired. It can be a tricky business figuring out not only who your audience is, but what to include in your manuals, guides, and courseware. Make no mistake, it is work to determine who your audience is, but if you get it right, you can expect kudos – and more work.