Lately, there has been an interesting discussion about whether technical communicators shall consider organizational centric tasks and/or product centric tasks when writing end user assistance. The discussions are found here http://idratherbewriting.com/2011/12/26/using-tags-to-increase-findability/#comments and http://everypageispageone.com/2012/01/09/are-docs-a-responsibility-or-a-business-asset/. I will clarify my view in this blog post, but first some words about the process change taking place in our domain.

As you probably know, technical communication will not be tomorrow, what it used to be yesterday. There are a lot of changes going on, where internet and social media collaboration changes the way people communicate and find information. Many users are not consulting the manual the first thing they do when an information need arises. Humans tend to consult as “human like” information sources as possible when trying to find information. And, the internet provides many human like information sources. Is a technical communicator, making “traditional manuals” at all needed tomorrow? Will users find the information they need from other users, by asking someone on a social on-line forum or by reading answers someone else placed on a similar question? Will users talk directly to engineers on for example a user group mailing list, bypassing technical communicators? What is your role tomorrow?

This change is happening fast in some industry domains and slower in others. For some products, users may not even need information at all, since the product interface is communicating how the product is used, through natural mappings, logical constrains and visual clues (affordances). My viewpoint is that a manufacturer must do everything they can to make their users as successfully as possible. A user is successful when he or she can deploy and use the product as easy, efficient and securely as possible. A manufacturer must do everything they can, meaning to provide the correct answer at the time the user needs it, through the preferred information channel. A manual is one possible way.

Let’s assume that a manufacturer thinks that a manual is a good way of solving an information need of a user. The manual (the “starter set”) is made available to its user as the product is launched to the market. What type of information should the manual contain? Here, me and Mark Baker have different viewpoints. I argue that a manual shall not interfere with nor dictate how an organization shall run their business, meaning deal with organizational centric tasks. A manufacturer shall not explicitly demand a user organization to be set up in a certain way to use the product successfully, that is imply a set of roles, tasks and even departments. If I understand Mark correctly, he claims that a manual can (and must?) dictate how a user organization shall be set up to use the product successfully.

Implementing a product may very well mean that the user organization must radically change the process on how they are doing things, since the product means a paradigm shift on how something is done. But I argue that it is up to the user organization to decide on the change; they are clever enough to find it out. Instead of dictating how customers shall run their business, the technical communicator must focus on the product centric tasks. What do I mean? Continue reading to find out.

First of all, what are organizational centric tasks really? Let’s start from the beginning. An organization has business goals. The business goal is to increase revenue, market shares, customer satisfaction and decrease cost etc. The business goals are reached by setting up various organizational goals, such as sell more products or services, develop more usable and qualitative products, constantly focus on optimizing, automating, enhancing processes etc.  An organization sets up different processes, each defining who is doing what, when and why. An organization has employees, each employee having one or several roles. Each role has a responsibility to contribute to the organization goal, and in turn to the business goals. Each employee executes the responsibility, within the company process, by performing various tasks in their daily work life. The organization themselves actively defines the processes to be followed, the responsibilities and the task each employee must do within a given process. These tasks are what I call the organization centric tasks. It can be concluded that several (maybe competing) organizations in the same business domain, may have in general the same business and organization goals. But they differ in how the business and organization goals are reached, meaning how the organization is set up in terms of departments, processes, roles, responsibilities and tasks.

Now, the processes an organization is following may be un-effective. There might be smarter ways of doing things. New ways, supported by products developed by other companies; maybe your company. As when the computer entered the scene, allowing companies to process data in a completely different way than before computers. Or as when technical communication departments deploy a structured and modularized writing approach.

So, an organization may be aware of that there are smarter ways on reaching an organizational goal (such as cut cost etc). The organization starts to investigate and evaluate possible products that help them change the way things are done. They hire a consultant or talk directly to the manufacturer of a certain product type to help them. Or they look into the product manual to find out what the product can do. The organization makes ROI calculations, makes pilot projects, sets up requirement specifications, defines relevance criteria etc to get a complete picture of all factors. And finally they take a decision to buy a new product, maybe your product. The organization must probably train employees, maybe hire new people or form completely new departments.

The point here is that an organization is active; they are investigating, evaluating, making comparison, asking other organizations via social forums, changing the organization set up, following up etc. The managers within the organization know best how to change their own organization, given an understandment of what the product (supporting the new process) can do and what is required to make it do it. They know it best, meaning that they know their staff and their capabilities. A  technical communicator does not need to give instructions on how an organization shall investigate, evaluate, make comparison, ask other organizations via social forums, change the organization set up, follow up etc. Each organization already has processes on how this is done.

This is how an organizational centric task manual could start: “Your organization is probably un-effective, since it still does process “X” following the old tradition “Y”. To be effective you need to follow process “Z” which our product supports. To use our product effectively, your organization must have departments “X”, “Y” and “Z”, roles “A”, “B” and “C” having competences 1, 2 and 3. Role “A” must do tasks 5, 6 and 7 as described on page xx, role “B” must do tasks 8, 9 and 10 as described on page yy and role “C” must do tasks 11, 12 and 13 as described on page zz. When evaluating to buy our product, department “X” must do tasks “E”, “F” and “G” and then report to department “Y”. If your organization is not set up like this, you must change it”.

But, on the path to nirvana, a manufacturer could very well discuss and give its users advices about organizational centric tasks on public forums. I believe that there is a difference between giving advices and discuss problems on a social forum and officially state in a user manual that the user organization must be set up according to a certain model, to use the product successfully. Furthermore, a manufacturer is not broadcasting the exact same information on every possible communication channel. Some type of information is best conveyed on a certain channel.

So, what type of information should a manual contain? Let’s look at my definition of product centric tasks. First of all, certain users on certain markets do have problems, needs or requirements they want to solve. This is recognized by a manufacturer, who designs a product that can help an organization to solve the problems, needs or requirements. The manufacturer is marketing the product on that market since they believe that they can earn some money. I call the problem, needs or requirement an organization or individual user want to solve, the primary goal. The primary goal of a user organization can be to optimize, automate, transform, secure, reduce etc something and, as said above, they actively evaluate products that they believe can help them reach the goals.  Thus a product or service is designed for a purpose, and that is to solve the user primary goals. As a consequence, primary goal can and must be mapped to business and organizational goals. And, a user manual must include information on which primary goals the product can solve to help the user organization evaluate if the product can or cannot solve their specific business/organizational goals.

There are products that completely changes the way something is done.  Some organizations may not set up primary goals to change something completely, merely they set out more modest goals. But, after reading the manual and evaluating the product, they may very well change their primary goal objective and buy the product. So the manual is used to sell the product. There are also some types of products that are designed to target a well defined and standardized process followed by certain organizations. This means that each organization is having the same set up of roles, tasks and responsibilities. In such a case, the product centric tasks may very well be aligned to the organizational centric tasks.

A user manual must state what the user must do to make the product solve the primary goals. The user must reach for a set of secondary goals; to install, configure, verify, use, evaluate etc. To reach the secondary goals, the user must perform a set of tasks: the product centric tasks. A manual must include the instructions on how to carry out tasks to reach the secondary goals, without requiring that the task must be done by a certain role, located in a certain department. If you work according to SeSAM, an assumed knowledge level must also be stated. That is, the instructions must be written assuming that the user has a certain level of knowledge.

After reading the manual, the user organization concludes that some changes must be done to their organization and some staff must be properly trained or convinced. So finally, an organization is themselves deciding on what to change and how; they don’t expect the manual to state which new departments to build. I don’t see the case when a manager is looking in the manual to find out how to change the department structure. Do you?

My concern is that many technical communicators are focusing too much on organization centric tasks, thereby missing an important aspect. Technical communicators (including myself some years ago) focus on describing and analyzing user organizations, where user groups and target audience are identified to try to build a universal set up of roles/groups and predict their tasks. But why is a user doing a task? Users don’t do tasks because it is fun to do them. As a result, user manuals are often introducing a lot of tasks, but technical communicators often miss to provide the “meaningful glue” that helps the user understand what the purpose and goals of doing a set of tasks are. The missing aspect is what primary goals the product is designed to solve. That’s why I developed SeSAM. SeSAM is a methodology that helps technical communicators focus on how their product can help users becoming successful, thereby making documentation a business asset.