Best Practices for Defining Your Target Audience Before Writing Documentation
Have you wanted to know how to understand your users better before documenting your product? Have you been in a situation where you have the personas you’re writing for, but do not know the details behind the research that was done to arrive at these personas?
Then, it’s time to take a step back and do some research. In one of my previous blog posts about information architecture, I wrote about “User Research and Analysis”, and mentioned that user research helps you define personas. In this blog post, let’s take a deeper look at personas to help you understand how this aspect of information architecture improves the quality of user assistance.
Consider the following example: Your team is building a mobile application and there are a lot of administration activities involved to set up and use the application. The people who would be using your application could be design engineers or project managers or vendors.
Now, with this context, if you need to start structuring and writing your documentation, your first question should be, “What am I writing and who am I writing for?”. Given just the roles of the people that will be using your application, it is not enough information to understand your users. Understanding and characterizing your target audience is more important that the final definition of your audience itself. So, to understand your audience, research is a must.
You should research about the users who would read your documentation, identify the customers who would use your product, and characterize them based on this research. This characterization is what results in personas. Personas help to guide you in writing information in the correct format that’s useful for a specific audience. During the research, if you find out that a persona prefers videos in a specific channel over written content, then creating videos and publishing them in that channel would make more sense than writing a PDF document. Similarly, if a persona prefers printed documentation, it doesn’t make sense to create videos here.
If you’re writing API documentation, research about the top development languages that your API consumers use. The percentages of users in the different development languages will give you an idea on whom to focus on first. These are some of the important conclusions you can draw based on user research and personas.
The word “research” might sound like a strong word to use. In reality, research can also be as simple as asking your end users or your documentation readers a few questions. It can be about just knowing who your end users are and where they work.
For example, can you name a customer that you personally know? Can you tell the name of a company that is your client? Do you know where their office is? And what they use your application for?
If you can answer these questions – congratulations – you’ve just done some research!
Of course, that’s just the start. More importantly, you need to ask more relevant questions that will help you further customize the documentation you will be writing or the user assistance you will develop. But you are already on a good track – your next steps should be to go find more customers to interview.
Conducting usability tests, card sorting workshops, and interviewing your stakeholders are some of the user research methods that are simple, inexpensive, and easy to perform. They will help you in defining a persona.
The research would help in establishing demographics such as age, educational and professional background, technical proficiency, and geographic location.
You also identify the problems that are being faced by a persona, which your product can solve. This is how you connect the personas and their problems to your product, and then write documentation to answer the right questions.
The point is to understand what a persona is facing. When you create user assistance keeping a persona in mind, your content becomes a hundred times more useful!
It’s possible that your research results in multiple personas. Here as well, prioritize based on the percentage of users that a persona represents and decide which persona you need to address (and help) first with your documentation.
Remember that perfectly written documentation, if it has no connection to your audience and their needs, will be useless at the end of the day.
Did this blog post help you in understanding the need for personas and their importance in user assistance? Does it encourage you to be a part of user research before writing product documentation? What are your thoughts on personas? Tell us what you think about it using the comments. Do share this blog post with a friend who might benefit from it.