November 13, 2014

Why Should Technical Communicators Avoid Target Group Analysis?

Us technical communicators have been taught that end user assistance for a product should mostly include instructions addressing specific user tasks. But how do you know that the method you’re using to identify these tasks, such as Target Group Analysis, actually leads to the information users are searching for?

I have always thought that grouping users into target groups, like installer, operator, etc., and analyzing the tasks each group is supposed to perform, is the wrong starting point for anticipating the information needs of users. Especially when designing information intended to support a user of your company's products.

The purpose of this article is to show why Target Group Analysis is a dangerous thing for technical communicators creating assistance for a company's products, and to suggest an alternate solution. Here, I will stress the importance of understanding different types of goals as a starting point for identifying what questions users ask.

Designing usable user assistance starts with understanding what information users need. If you do not know what users want and end up writing information your users aren’t actually searching for, any investment to dress up such content (for example, by making it Googlable or moving it to DITA), will not be returned.

Why do users ask questions in the first place?

Individuals ask questions because not knowing the answer is getting in the way of them reaching a specific goal. Humans are constantly developing goals and setting out to accomplish them. Thus, we technical communicators need to know, not only what tasks, but, what goals a user is attempting to accomplish before we can properly predict questions and write the appropriate answers.

Distinguishing between three types of goals

Awareness of the goals users are attempting to reach is also the key to identifying, and distinguishing between, different types of tasks. In fact, it is better to focus on goals rather than tasks when designing user assistance.

I distinguish between three types of goals an individual may pursue:

  1. The goal of wanting to become a (better) professional practitioner in a field
  2. Goals related to fulfilling responsibilities assigned to a specific role in a company
  3. The goal of making a product complete something it was designed to do

Is your intention as a technical communicator to support the goals of individuals striving to becoming better practitioners in their field, to support the goals specific to different roles in certain companies, or to support users of your company's products? Let's look more closely at each of these goals, as a way to understand the difference.

The goals of a professional practitioner

Many of us are professional practitioners in a certain field. Perhaps you have learned how to master your profession from an educational program or apprenticeship. Being a professional practitioner means mastering certain skills which have evolved through knowledge sharing in a community of practice.

The goals a professional practitioner might have include learning new skills, enhancing existing skills, mastering usage of typical products in their field, and staying informed about relevant new trends and topics of discussion.

To reach a goal, a professional practitioner often seeks information— by attending conferences or courses, asking questions of colleagues, reading blogs, searching online forums, etc. For example, I’m trying to learn how to mix recorded rock songs as a mixing engineer, and use as a forum for learning how to master the skills I need.

The goals associated with a role in a company

You may want to become a better professional practitioner in order to become employable. Once employed in a company, you have a role and a responsibility, which implies understanding what is expected of you, and awareness of company policies and processes.

The goals associated to a given role are generally pre-established by the company, or within the context of a particular project, or customer responsibility. A service engineer is, for example, responsible for de-installing, replacing, and servicing parts of products.

When trying to reach role-related goals, we often end up asking questions and searching for answers. We ask managers and colleagues, or attend internal courses and workshops. At times, we might search the internet to learn how others in similar positions have done.

The goals of a product user

When we use a product as a practitioner, or when having a role in a specific company, our goal is to make it accomplish what we believe it can do— for example, to automate, optimize, or secure something. A user is asking questions because not knowing the answer is getting in the way of them reaching their goal, as depicted in article 6 in this series.

When does Target Group Analysis become a problem?

First of all, what is "Target Group Analysis"? Technical communicators often perform "Target Group Analysis" and develop personas as a method for identifying which tasks to write. We establish audiences, such as “operators," "system administrators,” or "service engineers".

We list the tasks that each audience group is supposed to perform. We write a task topic for each task. Then, we identify descriptive information supporting the user in executing the task. DITA is built on this way of thinking.

If you apply such Target Group Analysis you’re actually addressing the goals of a practitioner, or those related to a specific role in a specific company. This is fine, if that is your intention. But when we define target groups and analyze their tasks, we fool ourselves into believing that every user in every company shares the same characteristics.

The result is that the content becomes very generic. Since the characteristics that define a practitioner or a particular company role differs between cultures, businesses, market contexts, genres, etc., generic content isn’t applicable for anyone. To make content usable, you would need to address each of the afore mentioned characteristics. However, you would likely overrun the budget if you tried to address each individual role or practitioner.

But even more so, Target Group Analysis becomes problematic if your intention is to address the users' goal of making your company's product complete something it was designed to do.



Target group analysis, a method for analyzing information needs among users, introduces a number of problems which may make the resulting content un-usable for your users. (Image courtesy of DigitalArt at

Why is Target Group Analysis a problem when assisting product users?

Don't get me wrong. It is crucial to know your target audience, and conducting a Target Group Analysis is one way of accomplishing this.

But the problem lies in the fact that such analysis leads you to organize content around the groups you’ve identified. You might end up defining different manuals, labeled according to specific target groups, such as “Operator,” “Service Installer,” etc, including the information each group is anticipated to need. As such, you address the goals of a practitioner, or those related to a specific role in a specific company.

Most users consult product user assistance to get answers when stuck in product use. They generally do not seek such user assistance when their goal is to excel at being a practitioner, or to get advice on how to fulfill a company role responsibility.

A user, wanting to know how to make the product do what is was designed to do, becomes frustrated if the content in product user assistance is written according to the tasks of a practitioner or company role, organized in manuals labeled according to specific target groups, such as “Operator,” “Service Installer,” etc. They don’t know if they are an “Operator” or a “Service Installer,” and furthermore, they will find that the information is only valid for someone wanting to reach their goal as a practitioner or other specific company role. They will not find the answers they are looking for in order to reach their goal of making the product complete what it was designed to do

What is the alternative to Target Group Analysis?

If your intention is to support the users of your company's products, then begin by zeroing in on the goals users set when trying to make a product complete what it was designed to do. For example, as depicted in article 5 in this series.

  1. If a user is unsure about what your product can do, they set goals to understand and evaluate what your product is all about on a general level. Users ask questions such as, "What is this product all about?” And, "When is it used to do what?"
  2. If a user knows that your product is suitable for their needs, they may set a goal related to finding out if something specific is possible. Users ask questions such as, "Is it possible to reuse topics?"
  3. If a user knows that its possible to reuse topics, they may set the goal of actually reusing topics. If they don’t know how, they might ask questions such as, "How do I reuse topics?"
  4. If a user knows how to reuse topics, they may set a goal to, for example, locate the "reuse icon" in the user interface (since you must click on it to make it work). If they do not know where it is, they might ask questions like, "Where is the reuse icon located?".

As you can see, these goals are not target group specific. I argue that you shouldn’t try to categorize these goals and their questions into target groups. This is because any practitioner or role may ask any type of question.

Instead, make answers available in a web knowledge base, such as Excosoft exFinder, and allow your customers to set up user profiles. Then, when someone with a particular role is logged in, the answers that do not apply to them are simply filtered out.

SeSAM is a methodology for designing according to dialogism, or for the searching user. Contact Information Architect Jonatan Lundin at jonatan.lundin@excosoft.comto learn more. 

Explore previous editions of the Designing for the Searching User article series via the links below, and stay tuned for upcoming ones! 

Previous series editions: Part 1Part 2Part 3Part 4/Part 5/Part 6/Part 7/Part 8

About the author

Jonatan Lundin

Jonatan is a pioneering information architect backed by over 20 years dedicated to XML documentation, and designing for findability.

Post Comment


  • Excosoft
  • Information Design
  • User Experience

Latest posts

More from Blog & News