A technical product needs documentation that helps the end user understand how the product is used to solve the needs, problems or requirements the user is facing. The documentation includes task information (as a DITA task topic) to instruct the user on how to do things.

But how does the technical communicator identify the user tasks? Let’s look at the traditional task analysis approach along with its challenges.

A technical communicator often starts by identifying users and the goals they are trying to accomplish when using the product. Then the technical communicator identifies the task the user must do to reach the goals. Also the environment in which the tasks are carried out must be analyzed. Then it is important to find out how the users best learn to do the tasks. Maybe reading about the tasks is not the very best way of learning, but attending a training course. Based on an assumption on what the user already knows prior to do the task, the needed amount of information in a manual can be elaborated. Content, typically task information and descriptive information, that help the user understand a task, can be created given the identified users and knowledge of their goals and task. Hierarchical task analysis (HTA) can for example be used to model the user tasks in hierarchies.

But let’s look at some challenges using this approach. What is a user? Imagine a technical product that is used in many different markets around the globe where there might be hundreds of different user organization, meaning that there are many user roles involved in using the product. In one (small) organization A in country 1 there might be one (1) individual/role doing all tasks for our product like engineering, installation, commissioning, operating, maintenance etc. In another (large) organization B in country 2 the corresponding tasks are divided across many individuals/roles that together do the same set of tasks for our product as the individual in organization A is doing. Also the way the product is used, meaning the way the tasks are carried out, can differ from organization to organization. Which market, country, organization and “user resolution” shall be targeted in the task analysis? Is a user (or target audience) a role, occupation, individual or education level in a certain organization? It will surely be costly to analyze all user organizations on all markets to try to identify the different “user resolution”. Furthermore; shall DITA content be packaged in manuals according to the user resolution in the large organization or in the small one?

It may also be difficult to do user and task analysis if the product being documented is totally new, meaning that no users has any experience of using the new product. Maybe the product includes a new nice feature that no user is aware of; how do we capture the user tasks in such a case? Do we simply say that if none of the users are aware of the feature we can leave it out in documentation? Furthermore a product may include a functionality that is executed without the user doing any task. How do we capture the data we need to document such functionality? To look at users when identifying the tasks may also be a risk from a documentation project perspective, since the product must be fairly ready to allow users to use it. When the product is ready also documentation must be ready. Of course user task analysis can be carried out on product prototypes and mock-ups.

But one of the biggest challenges in doing user and tasks analysis the traditional way is the fact that we might end up in a situation where we are documenting how a certain role in a certain organization is performing its duties. This can imply that we, as technical communicators, are looking at tasks that are irrelevant to the work of documenting our product. The user may be working with other products and tools that are not in the scope of our documentation project. Take for example a process operator in a certain process plant. The operator may do many different tasks when using our product when a certain use case appears, for example acknowledging an alarm. When the user is acknowledging the alarm the user might cross check other products or inform another operator etc. Another process operator in another process plant, where our product is also used, may do the alarm acknowledgment differently and in a different order. Which operator shall we consider and what tasks are not of interest when documenting our product (for example informing another operator)?