Audience Analysis Tutorial

audience-analysis-checklist

Documents fail for many reasons. One common mistake is to adopt a ‘one size fits all’ approach to your audience. This works only when generic material, usually of a non-technical nature.

Audience Analysis for Technical Writers

When discussing Audience Analysis, David McMurray points out that, “for most technical writers, this is the most important consideration in planning, writing, and reviewing a document. You “adapt” your writing to meet the needs, interests, and background of the readers who will be reading your writing.

Online Writing Lab makes the point that, “In order to compose persuasive, user-centered communication, you should gather as much information as possible about the people reading your document. Your audience may consist of different people who may have different needs and expectations. In other words, you may have a complex audience in all the stages of your document’s lifecycle—the development stage, the reading stage, and the action stage”
In other words, the audience of a technical document is the intended reader.

If you don’t know who you’re writing for, you need to stop and figure out why these people will read your document.

Other examples

In the same way that Disney creates movies for kids, ESPN target basketball programs at sporting types, and The Economist send their glossy magazine for executives, all of these products are targeted at a specific audience(s) and deliver accordingly.

Audience types

When you start to analyze an audience, try to identify its type. These tend to fall into four categories:

  1. Executives who make decisions regarding product development and its role in the company’s overall success may have little technical knowledge but a firm grasp of how to position the product as a business asset.
  2. Software developers, who are less concerned with sales and marketing activities, need to know other details, such as the specs and installation instructions.
  3. Experts will have in-depth technical knowledge. They are most likely to have designed and developed the product in question. They’ll be interested in emerging trends and new technologies. How does it compare against the competition?
  4. Users will have the least technical knowledge. They simply want the product to work and ‘do something’ for them. They have little interest in its business goals, marketing promises, or technical architecture. Does it help solve their problems?

For a professional writer, knowing your audience is critical. If you get this wrong, you’ll miss the mark.

Audience Analysis in Technical Writing considerations

In addition to the types discussed above, you also need to factor in their:

  • Delivery – How will the document will be delivered (print, online, projection, PDA). Will it be read in the office, on the road, or in more stressful situations, for example, disaster recovery documents may be read in very hazardous conditions?
  • Experience – knowledge of the application to date
  • Needs – determine the reasons the reader needs to have this document and what they hope to accomplish with it.
  • Preferred document type – for example, do they have a preference or a need for printed or online material.
  • Training – likelihood that the person has had some (or no) training with the application. This may determine how much needs to get into the Getting Started Guide and/or the Introduction chapters.
  • When the document will be accessed (work, home, travel)
  • Where the document will be read
  • Why the document will be accessed (reference, training)

Other factors to include:

  • Age
  • Culture
  • Language
  • Level of education
  • Needs and interests
  • Skills

All of those factors will contribute to how the document is written and delivered.

How to define an audience

Depending on what you’re writing, you may have just one audience or possibly several.

For example, different chapters in the TV guide will be targeted at users with simple, moderate, or advance levels of proficiency.

  • How many audiences do you have? List them. Start by identifying their needs.
  • What do they hope to achieve?
  • What is most (and least) important to them?
  • What should they do with the document?

Audience acronym

Wikihow provides this AUDIENCE acronym:

  • Analysis – Who is the audience?
  • Understanding – What is the audience’s knowledge of the subject?
  • Demographics – What is their age, gender, education background etc.?
  • Interest – Why are they reading your document?
  • Environment – Where will this document be sent/viewed?
  • Needs – What are the audience’s needs associated with your document topic?
  • Customization – What specific needs/interests should you the writer address relating to the specific audience?
  • Expectations – What does the audience expect to learn from your document? The audience should walk away having their initial questions answered and explained.

It adds that audience analysis is part of the beginning stages of producing a target document. Whereas audience analysis does help to start off the project and lead the writer in the right direction, it is only one step in the formation of a document. It is beneficial to consult other rhetorical strategies that may help guide the writing process even more so.

Advantages of audience analysis

Knowing your audience lets you refine the subject matter so that it matches the reader’s needs. If you don’t know who you’re writing to, then you can’t achieve this.

Understanding your audience is the first step towards creating a healthy document. Before you start writing, define what the audience expects from the document. Imagine how readers will use it.

For example, imagine you are writing a manual on how to tune a High Definition TV:

  • What will your readers going to expect to find?
  • Will there be graphics and diagrams? Maybe screenshots of how to install parts.
  • What do they want to read? How to troubleshoot if they can’t find a channel.
  • What do they not want to read about? Its technical architecture and business plans.
  • Where are they going to read it? In their office, car, room, or even outdoors.

Here are some questions to consider when defining your audience:

  • How knowledgeable is the audience?
  • Before starting a project, I always ask my clients, “What do they already know?” The client should know his customer’s level of proficiency. If not, interview the target readers and determine their strengths and weaknesses.
  • What do they already know? Saves you from re-writing material.
  • What do they need to know? Allows you to focus on the gaps in their knowledge.
  • What background material should you provide to bring them up to speed?

How to keep readers interested

Sometimes you’ll have to work hard to persuade your readers to even open the first page. Writing a grant proposal means persuading the reader that your project is worthy of investment. They’re under no obligation to read it and can stop at any time and move onto something else.

Your success as a writer depends on grabbing their attention, keeping it and then encouraging them to take action – calling the sales office, for example.

For other projects, you may have a more captive audience. Internal documentation, memos, circulars, and other such publications are all targeted at your colleagues. To a certain extent, they have read this.

But you still have to make sure they understand the material. If not, you’ll be held responsible for such poor communications. When you consider it like this, both your internal and external customers have to be taken very seriously. Just because you’re writing for your colleagues doesn’t mean you can step down a gear. Rather, you need to be vigilant and avoid complacency entering your material.

How to write different types of information

For example, if you’re updating a User Guide, you may have to highlight how it differs from previous publications. Many readers will look at the introduction only (where you’ve discussed the changes) and skip to the sections they know best rather than read the entire document.

However, if you’re writing a white paper for a conference, you’ll have different writing goals. Your aim is to get their attention and persuade them to keep turning the pages.

So, how you present different types of information really matters. Is it new or old? An appendix or update? Is it neutral (i.e. sharing information) or sales-orientated.

Here’s another angle: consider whether the publication is technical (admin guide), commercial (case study) or promotional (press release)?

When you think about it, each type of reader is very different. Knowing their expectations helps fine-tune your material. Imagine if you didn’t know who you were writing for? Where would you start?

How do readers see you?

You can’t write in a vacuum. So, how others see you will determine the tone and position you’ll adopt when ‘speaking’ to others – just as it does when speaking to people in real life.

For example: consider a business plan where you’re requesting funds.

  • What’s your position to the Venture Capitalists?
  • How do they see you? Inferior, superior or peer?
  • What tone do they expect? Chatty, witty, and light-hearted? Maybe not!
  • How about a series of Standard Operating Procedures for a Military unit?
  • Again, what tone should you adopt?
  • When the solders read the instructions, what attitude would you like them to adopt?
  • Should they consider the SOPs politely, debate their meaning amongst colleagues, or accept it as a direct order from their superiors and act accordingly?

So, before starting, make a list of your target readers. Then, write a single paragraph outlining their needs. Prioritize their three main objectives and write your document around these. Later you can go back and refine the text to incorporate other topics that are close to their heart.

Understanding your audience is the first step in the writing process. Spend more time on this in your next writing project and you’ll see a considerable difference in the final publication.

Then go back and look at other documents where you did no audience analysis. The difference will be very obvious. Older documents will appear to be very coarse and immature; newer documents will have a more professional and solid feel to them. You know who you’re writing for and it shows.

Resources:

What are your thoughts on this area? Is it best to get something written up fast and circulated or is it better to be patient and go through the analysis phase?

Download these templates to start

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan