Defining the audience

From TechWriter Wiki

Jump to: navigation, search



Successful communications are those that meet the needs of the audience. In order to meet these needs effectively, it is essential to identify and understand the audience. The more that technical communicators know about the intended audience for their communications, the more likely they are to produce communications that focus on the needs of that audience. One of the first steps in planning any technical communication (training, documentation, one-off communications, etc.) must therefore be to identify and understand the intended recipients of the communication.

Defining the audience is not simply a matter of labeling the audience group in general terms, or counting the number of users. Determining that, for example, a training course on Order Entry will be attended by Customer Service Representatives, is of little value if the term 'Customer Service Representative' is only perceived as a generic job role, and not as a specific individual. Rather, defining the audience is a matter of understanding the nature of the audience - their level of technical comprehension, any relevant experience they may have, and so on. Once these factors have been understood, then the communication can be developed with these factors in mind. The main identifying factors of the target audience are:

  • Their general education level;
  • Their technical knowledge;
  • The environment in which they are working;
  • Their language;
  • Their nationality;
  • Their attitude.

General educational level

Documents should always be written using the correct comprehension level for the readers. For example, a document aimed at school children is likely to use a different vocabulary and grammatical structure than one written for graduates, even if the subject matter is the same in both cases.

You should therefore identify the expected education level and then choose a document format and vocabulary suitable for this level. It is important to note the word 'expected'. A given user group will always contain some high flyers, and also some also-rans who are trying to catch up. Taking an average in this scenario will therefore not necessarily produce an accurate portrayal. If possible, you should determine the minimum education level of the people that are expected to receive the communication. Note that the general educational level is normally sufficient - do the readers have college degrees, high-school diplomas, are they in primary school, and so on. The identification of specific qualifications is only likely to be required for highly targeted communications.

The user's educational level is also a good indicator of the familiarity with such navigation tools as tables of contents, indexes, glossaries, and so on. Even the simple aids many publications take for granted, such as hierarchical subject headings (especially those using a decimal numbering system - or worse still, roman numerals) may be unsuitable for audiences with lower levels of general education.

The general educational level is likely to be easy to determine in a work environment, where such information is likely to be written into the job description. For public communications, this is less easy to determine. In this case, you should try to determine the minimum educational level of the audience, taking into account national averages. For example, when writing instructions for a home heating system, it is safe to assume that the user is a homeowner, and therefore has a standard basic education. When writing instructions for a piece of hospital machinery, it may be possible to assume that the user has either a medical degree or specialist training (e.g. a Nursing course).

Technical knowledge

If the document is being written for a specific set of (known) users, then you may be able to assume that the readers will have a certain amount of prior training or technical knowledge. For example, if one is writing an owner's manual for car, one can safely assume that the reader knows how to drive.

Similarly, if a document will only be referred to after certain activities have been carried out (and, by inference, other documents have been read), then the knowledge required to carry out these activities can be assumed. For example, when writing instructions for changing a printer cartridge, one can safely assume that the reader knows how to switch on the printer).

If the documentation uses a specific technical terminology, or terms specific to an industry or occupation, then it is wise to check that the intended audience understands and is familiar with this terminology. If they do not, then it may be necessary either to remove such terminology, or to provide a glossary of terms.

Identifying the level of prior technical knowledge the audience has will allow the Technical Communicator to determine the amount of technical knowledge that they either must include in, or can exclude from, the document. Specifically, it will allow the Technical Communicator to decide whether they need to go 'back to basics', or can omit 'known' information that would otherwise 'get in the way' of the required information.

Working environment

It should go without saying that for a document to be useful, the reader must be able to use it. It is therefore important to consider the environment in which they will be reading the document. The first thing to bear in mind is that for many technical documents, the reader will want to refer to the documentation whilst they are actually using the product to which the document relates. Therefore, consider the type of product for which you are developing the documentation, and the uses of this product. Specifically, consider the following:


Will the user be sitting at a desk when they are reading the document (as will tend to be the case for software documentation)? If so, then it is reasonable to assume that they can comfortably open the manual on their desk. However, consider exactly how much space they will have to spare on their desk - they may well have other documents or manuals on it. A perfect example of the solution to this problem (and of the problem of keeping the documentation and the product together) is the old IBM 3270 terminal. This terminal (long now obsolete) had a huge, heavy, metal keyboard attached to it. The keyboard had a kind of wrist-rest built into it (even though this was before ergonomics was considered an issue!), the top of which flipped down to reveal - voilĂ ! - the user manual for the 3270 terminal!

Even if the user is sitting at a desk, consider whether they will be able physically to reach the documentation. For example, if the documentation is provided as a set of manuals that sit on a shelf, is the shelf within reach? If the user has to do more than stretch out (for example, walking to the 'manuals cupboard' at the end of the corridor) then they may simply not bother. In this latter case, one should consider providing some form of quick-reference card or booklet that the user can keep permanently on their desk (but that directs the user to the (remote) manuals for more details, should they require them).

Also, consider cases where users will not have a permanent desk or office allocated to them. This is a growing trend in some companies, especially in Sales organizations, where staff are expected to be out at the customer's site for the most part, and only get the use of a shared docking station when they visit their own offices. Staff of this type will not thank you for requiring them to lug a heavy manual around with them - they are more likely to just ditch it! In this case, one should consider providing the documentation on a CD-ROM that the users can carry around with them, and use either on their laptop PCs (should they have them) or on the 'communal' PC they get to use at the office (or at home).

There will also be cases where the reader of the document does not even get to sit down. Consider warehousing staff who are walking around taking inventory, and recording the details in a hand-held device (such as a mobile barcode scanner). Here, the user will literally have to carry the documentation around with them and refer to it standing up, possibly using only one hand (the other holding the portable device). In this scenario, producing a set of hand-sized spiral-bound cards that can be flipped through by thumb (therefore with sturdy index tabs) would be a suitable option.

System access

If on-line documentation is being produced, then consider whether the user will actually have access to it. If the documentation will be placed on a server then will the user always have access to this server? If the documentation is instructions for a software system then will the user be able to display both the system and the documentation on the same screen, or can they at least toggle between the two? If the documentation is to be delivered on CD-ROM, then does the user have access to a PC with a CD-ROM drive?


What kind of lighting will be available at the time that the product is used - and therefore at the time that the user is most likely to refer to the documentation? You cannot always assume that light will be available. Consider, for example, the instructions for starting an emergency generator - the chances are that if the user needs to start the emergency generator, the power - and with it the lighting - is out. Although providing documentation in luminous ink is not really an option (I've tried it - it isn't very easy to read!), providing ultra-large lettering or symbols, in high-contrast colors is. You may need to light a match to read it, but at least you don't need to hold the match so close to the paper that you risk burning it!

Noise Level

What is the noise level in the environment in which the documentation will be used? The primary concern is any ambient noise that would prohibit the user from using the communication effectively. For example, if the user is working on a noisy shop floor, then they may not be able to concentrate on long tracts of text. Even in an office environment - especially in open-plan offices - there may be too much background noise for a user to listen to any form of audio communication (such as a Computer Based Training (CBT) course). Consider also the impact of any noise generated by the communication on the environment in which it is being used. For example, a presentation with sound effects would be unacceptable for use in a library. Similarly, it may not be possible for users to play CBTs or listen to voice prompts in an open-office.


How clean is the environment in which the communication will be used? For the most part, the concern here is that the environment is dirty to the point where the communication medium needs to be designed specifically to cope with this. For example, consider a car maintenance manual - this is likely to be used in a workshop or garage, where there is oil and grease - quite probably on the hands of the person who will be turning the pages. Here, it would be advisable to provide the manual on hard-wearing paper, perhaps laminated or waxed. Conversely, there may be situations where it is necessary to ensure that the documents themselves do not detrimentally impact the working environment. Specifically, consider documentation that is used inside a clean room, or in an operating theater. Here, it is important to ensure that the documentation does not retain or transmit dirt or dust. It such environments it may also be a requirement that the communication media can be cleaned, or even sterilized.


The underlying question when identifying the user's language is: Will the users be reading the documentation in a language in which they are fluent? Generally, the language in which a user is (most) fluent is only their own (native) language. However, it is also worth considering other languages spoken by the user or user group. For example, it is a requirement in many large American multinational corporations that employees are fluent in (American) English - regardless of their nationality. In these cases, it may be safe to assume that communications provided in English will be acceptable. (Although it is wise to put this theory to the test, as "fluent" is open to subjectivity!).

If the intended user of a communication is (truly) fluent in the language in which the communication is being provided, then there is no issue. If they are not - for example, Italian users reading English documentation - then there may be additional considerations that need to be made, depending on the degree to which the user can 'interpret' the communication.

If the user is completely unable to understand the communication in the language provided, then clearly the documentation needs to be provided in another format. The obvious approach is simply to have the communication translated into the native language. However, there may be other possibilities - for example, it may be possible to provide short communications (such as posters) in pictorial - wordless- form.

If the user has a basic grasp of the language in which the communication is provided, but falls short of fluency, then it may still be possible to provide the communication in the source language, in a simplified form. By keeping sentences shorter, by keeping to the 'one-word-one-meaning' rule, and by refraining from using vocabulary not in common parlance (unlike this clause!), it is possible to provide communications that 'foreign' users can still use effectively. The ultimate conclusion of this approach is to use Simplified English, where only a specific subset of words can be used. Many organizations find this to be too restrictive, but it is possible to define a workable compromise between Simplified English and 'full-blown' English usage.


When providing documentation to users of a nationality other than your own, you should give extra consideration to cultural sensitivities. For example, if you are providing communications to users in Saudi Arabia, then pictures of women in working situations should not be used in documents, and female voices should not be used on voice soundtracks for Computer Based Training or other audiovisual communications. This is because women are not allowed to work in Saudi Arabia - documentation featuring women in work scenarios would be considered at best insensitive, and at worst insulting.

One should also take care to avoid anything that could be considered politically insensitive. Although it is unlikely that technical communications per se would veer into political territory, it is possible for a political land mine to be accidentally sown in a publication. For example, a diagram of a world map that happened to show Tibet as a separate country would be considered unacceptable in China (the documentation would be considered subversive - or 'splittist' to use Chinese terminology - and would likely be burned!).

There are many other instances which highlight the need for care in international communications, such as:

  • The use of specific colors - Red represents prosperity in China, but death in Africa;
  • The use of 'standard' symbols - The standard symbol for an electrical socket in America differs from that in most other countries;
  • Time and date formats - "January 7th 1988" is written as 01/08/98 in America but 08/01/98 in Europe;
  • Number formats - "One thousand to two decimal places" is written as 1,000.00 in most countries, but as 1.000,00 in Germany.

Overall, when writing for a specific nationality, one should take the time to learn local conventions, symbols, and cultural interpretations, and then write the documentation with these factors in mind. When writing a single communication for a number of different nationalities, it is best simply to avoid using anything (words, pictures, etc.) that could cause offense to any culture (as far as this is humanly possible!).

Attitude and motivation

The reader's attitude is not normally a factor that is considered, but it is a factor that can make the difference between a successful document (i.e. one that is read) and an unsuccessful one (i.e. one that is not). In an ideal world all readers are happy and motivated, and approach each document with a positive mind. However, we do not live or work in an ideal world. Instead we live in a world that includes disgruntled employees with attitudes and hidden agendas. Fortunately such extreme cases are rare; instead, we are more likely to come across readers who think that they 'know it all already' and that there is nothing that the document can teach them. Both categories of 'readers with attitude' are likely to approach the document negatively, and so it will be necessary to work harder at 'winning them over', in order to get them to read (and re-read) the document.

There are a few types of resistance that are relatively easy to overcome. These can be identified by the questions the users are likely to raise (either verbally or - more likely - mentally).

Why do we need this document?

With this type of resistance, it is necessary to convince the user of the usefulness or worth of the documentation. For example, if a policy document has been written to ensure a common approach to a specific activity, then explicitly state that this is the purpose of the document. In some cases it is a useful tactic to couch the wording of the document in such a way that it subtly implies (to the reader) "we know you know this, but we're getting it down on paper for everyone else's benefit". It is also often useful to specify the reason for producing the documentation. For example, if the documentation is being produced as a part of ISO 9000 certification, then state that the document has been produced for ISO 9000 compliance, and that it is a requirement of this certification that the documentation be understood and adhered to by all employees.

Why are we doing it this way?

With this type of resistance, the user is actually reading the documentation, but they do not necessarily agree with it. This can lead to them skipping the parts they don't agree with. Here, it may be necessary to provide more explanatory material, and to justify (for example) why specific tasks need to be carried out. For this type of resistance it is also useful to specify the consequences of not reading and following the documentation. This is best done at a personal level - ensuring that the user understands that they personally will be worse off (in terms of increased workload, greater difficulty, etc.) if they do not read and adhere to the documentation.

What's in it for me?

With this type of resistance, the user does not refer to the documentation because they do not feel that they have anything to gain from it. Generally, these are users who feel that they know everything contained in the document already. Here, it is necessary to demonstrate to the users that they will benefit from referring to the documentation. The best way to do this is to provide 'value-add' information or services within the documentation. For example, don't simply reword or reformat what the user knows already - tell them something that they don't know, or provide information that they may have scattered across several other sources in a single source that is easier to use.

See also

Conducting an audience analysis

Personal tools