How to do an Audience Analysis
Step-by-step with examples
Audience analysis is used in many fields, from public speaking to marketing, product design to documentation, with the focus on understanding the needs and wants of your audience.
The goal of audience analysis is to gather measurable information about your audience so that you can better tailor your content to your readers. Your audience is who will be consuming your content. In public speaking, this would literally be your audience. For marketing, it's your customers or leads; for product design, your users; for documentation, your readers.
In this article, I’ll be focusing on audience analysis for documentation, but this information is applicable to most scenarios.
1. Background
How familiar with the topic is your audience?
What is their technical level?
What are your average user’s knowledge, experience, and familiarity with your topic? For example, if you are writing instructions for a Linux user, are they familiar with the command line, or do they only use the GUI (Graphical User Interface)?
If you assume a user is familiar with a concept, then you risk your users getting frustrated with your product (or instructions). If you assume they aren’t familiar, then you need to spend the time and effort to add background information to your document. Don’t assume, find out.
This understanding will shape the way you preface steps or instructions, and how you write as a whole.
Example
Take the following two definitions:
Algorithm: An algorithm is just a recipe for a computer. However, sometimes the steps in that recipe require computers to determine their own decision.
(Interesting Engineering)Algorithm: An algorithm is a finite sequence of well-defined, computer-implementable instructions, typically to solve a class of problems or to perform a computation.
(Wikipedia)
Both definitions are correct but are aimed at different audiences. The first definition is aimed towards a non-technical user, while the second is aimed towards a more technical user.
2. Needs and situation
What do they need?
Where/when/why/how will they be reading?
What is your user expecting to learn from your document? This is the need. Where will the user be when they’re consuming your content? This is the situation.
Your user’s need and situation will affect your choice of medium — how your information is presented. Some different medium types include:
- Printed word (online or physical)
- Spoken word
- Graphics
- Video
Example
The following depicts two different ways of teaching someone how to perform CPR and basic first aid.
The quick reference poster is designed to be used in the moment. The reader needs to learn how to perform CPR in the middle of a medical emergency. They need the simplest, quickest way to digest information, hence a poster using graphics and direct instructions.
The training book is designed to provide help well before an emergency and has room to cover more in-depth information than can fit on a poster.
3. Attitude
Is this a voluntary or captive audience?
Typically applied to speeches, the attitude of your audience will also affect your writing. As a technical writer, I’m usually dealing with a captive audience. My readers are interested in my documentation because it helps them do their job.
Will they read everything I write? Nope. A captive audience is likely to just skim your content looking for key phrases, interesting headings, or relevant images. To cater to a captive audience, spend a little extra time explaining the importance of the topic, and edit for scannability.
The inverse is a voluntary audience. You may be explaining a topic that interests someone, and they’ve sought out your content over other choices. These audiences are much easier to address, and you can usually inject a bit of personality.
4. Culture
While less ubiquitous than the previous three, understanding the culture of your audience can also significantly help when imparting information. There are a lot of great resources on writing for a global audience, but here are a few key points:
- Be aware of number formats. Dates, times, monetary and numerical amounts may follow a different format. Whatever you choose, be consistent.
- Avoid colloquialisms, slang, and abbreviations. If you have to use abbreviations, always spell them out first.
- Replace pronouns with nouns wherever possible. For example, use “Processing your documents may take 15–20 minutes” instead of “This may take 15–20 minutes”.
How to Gather Information
There are many ways to get this information, some better than others.
In an ideal world, meet with actual members of your audience (end-users) to discuss their needs and expectations. This is referred to as a user interview.
The second-best option is to physically observe your audience while they’re using your documentation. What do they like? What are they struggling with? Is something missing? This is referred to as a field study.
Otherwise, here are a few more ways to get information if you find it difficult to get direct contact with your end-users:
- Surveys and questionnaires
- Analytics (such as Google Analytics)
- Brainstorming sessions
- Personal experience
How to Use This Information
Once you’ve gathered information about your audience, you need to put it into a usable format. The most common method is to create a user persona.
A user persona is a personification of a single fictional user, based on the needs and background of your target audience. Give your persona a name, age, job title, and personality.
You’ll likely have more than one persona, so you can aim specific content at your main user groups. In technical writing, you may have personas for Administrators, End-Users, Developers, and even internal employees. As you write your content, refer to your persona to ensure your content is tailored to the target audience.
Example
Here’s a mock persona based on an Administrator audience segment.
Conclusion
Audience analysis is an important tool, especially when writing documentation. Knowing how to tailor your content to the needs and expectations of your readers can be the tipping point between usable and unusable documentation.
I hope this information has been helpful, and thanks for reading.
