Chapter 3: Audience¶
This chapter discussed the differences between “personas” and “audiences”. The chapter claims that personas, while valuable, are not as useful as a well-defined audience. Understanding the audience helps guide decisions on content format and structure, as well as learning objectives and the appropriate level of detail. The best way to define an audience, according to the chapter, is to talk to them and listen to their feedback to understand their use cases.
Discussion Summary¶
We discussed how personas and audiences represent two different user-views and are often created by different people for different purposes. In the experience of discussion participants, personas tended to be created by sales or marketing or UX teams, and not with documentation in mind.
They often have too narrow a focus: personas created by the sales and marketing teams are designed to help sell or promote the product, however the person choosing or approving the product is not necessarily the person using it.
Even end-user personas can be too vague if not created with documentation in mind. One participant suggested the following useful distinction between personas and audiences: the persona represents who is reading the document and the audience represents why they are reading it. This also helps us to use both personas and audiences together:
The persona can suggest what the user’s role is and what tasks they are likely to perform, and a well-defined audience can help you understand why the person is reading the document, which in turn helps you set learning objectives. Users can belong to different audiences at different times, depending on what they are doing.
The audience definition might include their skill level or experience, as well as time pressures and environments. You might also need to break it down into “internal” and “external” audiences. The why also includes knowing whether the audience is accessing the content while performing the task, for example a “how to” guide, or whether it is in a training situation.
Understanding the audience and their goals means that you can write only what the user needs to know to achieve their goal. This means that you can keep the documentation simple and clear and avoid additional information that is not required. One suggested implementation of this was signposting users towards to other content that contains more information about edge cases or exceptions, another was creating separate content for beginners who might only need the basics and more experienced users who might want to use more advanced features.
If a document is feeling too “clunky” or complicated, it could be because you are writing for multiple audiences. By creating audience-focused documentation, and organising it so that each audience can easily find their relevant content, you can reduce duplication and increase clarity and quality.
We felt that as a whole, the chapter focused more on external customers (or our company’s customers) than it did on internal customers. The main impact of the internal/external audience differentiation is seen in how we access those audiences to gain information about them. This tends to be easier with internal audiences, because we often have more direct communication (although remote working can make this more challenging).
Face-to-face meetings were preferred for learning about the audience, but this is often challenging with customers where it requires travel, cost, and time. Other methods such as community forums and Slack channels can also help, although forums do not always take off.
We discussed that the best solution where direct customer access was not available was to talk to the people who do talk to the customers, such as working with Support and Implementation or Customer Success Managers. This got discussed in greater depth in the chapter about feedback.
