Readers Express their Purpose in Terms of Tools and their Features

One of the samples of an EPPO topic that I included in my book was a topic from the WordPress Codex on the subject of Using Themes. One of the key properties of an EPPO topic is that it serves a specific and limited purpose. I identified the purpose of this topic as enabling the reader to use themes on their WordPress site.

One of the reviewers objected that the user’s real purpose was not to use themes, but to style their site. I can understand where the criticism comes from. Those of us who favor task orientation in technical communications are quite sensitive to anything that smells of its opposite: feature orientation. We don’t want people to be writing topics on the File Menu, for instance. We want them to focus on things that the reader is trying to do.

The root of this objection is the idea that the user’s purpose is never to use the tool for its own sake, and therefore that their purpose can never be stated in terms of using a tool or its features. This sounds fine in abstract. But it doesn’t work in practice. The fact of the matter is that when users are searching for technical content, they state their purpose in terms of their tools and their features all the time.

Why do they do this? The underlying reason for someone to use a WordPress theme is because they want to change the appearance of their site. On the other hand, a theme is not a button or an interface widget. It is a major architectural feature of WordPress. As such, the reader may well have seen the advice to use themes on any number of websites, or have visited the site of a theme vendor. By the time they hit the WordPress Codex, they know about themes, and they know they want to use them. What they are looking for, at that point, is information on how to use themes.

This is what we might usefully call a derived purpose. It is not the reader’s original motivation (wanting their website to look different, or perhaps wanting their website to generate more sales), but it is the task they are now trying to accomplish: a purpose derived from their original motive and the architecture of the system they are using.

Invictus yacht

The user’s real motive for using themes on their WordPress site.

We can’t ignore derived purpose. Our job is not to trace back the reader’s motives to their origins. (They want to change how their website looks to attract more visitors. They want to attract more visitors to sell more widgets. They want to sell more widgets so they can afford to live on a yacht in the Bahamas. They want to live on a yacht in the Bahamas so they can party with the beautiful people. They want to party with the beautiful people to show the kid who bullied them in the third grade that they came out on top in the long run.) But titling our topic on using themes, “How to Live on a Yacht in the Bahamas” or “How to stick it to Ralphie McPhee,” is not going to improve its findability.

One of the key things we have to remember is that the readers seldom if ever come to documentation with a simple desire untouched by any taint of implementatio. Desire leads us to planning. Plans lead us to tools. Tools lead us to confusion. Confusion leads us to documentation. By the time we reach the documentation we are usually immersed in the tool and familiar with at least some part of its feature set and vocabulary. That is the context in which we frame the questions we search for or consult the documentation to answer.

Our job is to make content available to readers in ways that the readers can find it and use it. Readers very often search for content based on their derived purpose, because that is how they understand their current task. And they very often think of their current purpose and their current task in terms of getting their tools to work they way they want them to.

Task orientation is therefore not about avoiding the mention of tools. It is about placing the discussion of tools in the framework of users derived tasks in a way that actually addresses the user’s purpose in the way the user understands it in their current situation.

, , ,

4 Responses to Readers Express their Purpose in Terms of Tools and their Features

  1. Pamela 2013/09/25 at 10:03 #

    An interesting defense. I’m surprised to find no other comments yet. I have a question, how can you know the derived tasks? Is it not just another assumption about the reader’s level of expertise on the tool or software product? Unless the derived task and the feature both use commonly understood language well-rooted in the problem domain (the ultimate purpose of the software, that is), I can envision justifying the same old feature orientation under this guise of a derived task.

    • Mark Baker 2013/10/05 at 23:47 #

      Thanks for the comment, Pamela.

      I think one of the reasons that the task based approach is hard to sell is that it is often presented as being so pure, and so founded in the readers ultimate purpose as to be unknowable.

      The derived purpose is much easier to know than the reader’s ultimate purpose, and much much easier to know than their original motive.

      If someone wants to transfer a call on their phone, that is a derived purpose. We don’t know, and can’t know, why they wanted to transfer the call. And it is hard to imagine how the person would express their purpose, or express their question without using the words “transfer” and “call”.

      Of course, in order to frame the question “how do I transfer a call”, the user has to know something about phones and phone networks. It has to occur to them that it is possible to take a call you are having with one person and connect them to another person. It is hard to imagine how a person could have learned of that possibility without having learned the terms “transfer” and “call”. It is hard to imagine why they would be looking for this in the manual if they had not learned that it was possible.

      When technology is that foreign to someone, they will almost certainly have to be taught by a human being in person. And, of course, most product are not sold to or used by people who are that unfamiliar with them. The mainstream bread and butter consumer buys stuff they understand to do tasks they understand, and for which they have a vocabulary.

      Yes, there are cases where new products deliver brand new capability that people have never seen before. But people don’t go looking for that capability. The information has to be pushed to them. And when we push it to them, we have to give the feature a name.

      And frankly, very little genuinely new functionality is created. There is not one thing that a smartphone does that people didn’t do before with different tools. If you want to describe those new features on the phone, you will do so in terms of the old tools that people already recognize. The computer industry has always done this, which is why we talk about windows, walls, home, files, clipboards, texts, etc.

      Task based documentation has to be expressed in the language that people use to describe their tasks, and that, to a very large extent, is the language of tools.

      Where feature-based documentation fails in not in naming features, but in not tying them to tasks. We can’t create effective task-based documentation if we refuse to name things by the names that users commonly give them. And I believe that the impression that that is what task-oriented documentation means is one of the things that has held back its adoption.

  2. Leigh White 2013/10/04 at 18:02 #

    I think this may be only partially true, depending, as most content does, on the target audience. An experienced user is very likely to express purpose in terms of the tool and its features. A novice user is much less likely to, simply because he or she doesn’t know the tool well enough to know the features. It’s comparable to a novice do-it-yourselfer going to the hardware store and asking for “one of those semi-circular bracket things that you use to attach a pipe to a joist,” whereas an experienced do-it-yourselfer simply asks for a “tube strap.” I also think it’s not necessarily true that “By the time we reach the documentation we are usually immersed in the tool and familiar with at least some part of its feature set and vocabulary.” My first day as a technical writer, I was told to create a user guide for an appointment scheduling application using FrameMaker. I had never seen FrameMaker in my life. I turned to the documentation right away, with absolutely no tool knowledge whatsoever. I don’t think that’s atypical, especially when tool decisions are made by a small group of people for the larger group. Maybe there’s training, maybe not…it’s entirely possible that the larger group comes to the new tool cold. So while I don’t think we need to take derived purpose to its extreme, we do need to provide a means for users to find answers using non-techy, non-jargon, non-tool-specific vocabulary.

    • Mark Baker 2013/10/06 at 00:24 #

      Thanks for the comment, Leigh.

      John Carroll wrote, in the Nurnberg Funnel,

      The term novice is problematic for designers of training. Its use exposes a
      technocratic ideology of learning that is insulting. Adult learners can never be
      thought of as novices. They are experts, though perhaps in domains other than
      the one in which they are training.

      I too had never seen FrameMaker before the first time I was asked to write something with it. But I was not without tool knowledge. I had used other word processors and desktop publishing programs, and I had a knowledge of computer hardware and operating systems. I had also done writing and page layout using pre-digital tools. I had a vocabulary for my task and my tools, and if I hadn’t, the FrameMaker manual would have been useless to me.

      Can we imagine a person who has never seen a computer before, never written before, and never done layout before, who is suddenly asked to create a document in FrameMaker? Sure, we can imagine them, but are people like that ever going to be a significant part of Frame Maker’s market? Should the FrameMaker manual be written in a way that is entirely free of the jargon of writing, layout, computer use, and desktop publishing? Could it be?

      What would be the non-techy, non-jargon, non-tool-specific vocabulary for any of the functions that FrameMaker performs? Where will you find a uniform usage that all people inexperienced in this field would use and understand to describe the things in this field? If we are not going to use the vocabulary of tools, then we need another vocabulary, one that reader will readily recognize. What vocabulary is that, for the things we use FrameMaker to do?

      You can, of course, create an introduction to a field for complete newcomers. Such books have very definite value, but what they do, at every turn, is teach the vocabulary of the field. And by and large it is not the function of a product manual to teach the basics of a field.

      One the other hand, there are certainly some features in some products whose names are entirely obscure even to people experienced in the field. This is usually because of poor feature naming, but sometimes it is because the tool creates an entirely new approach to doing something, an approach for which no one has a vocabulary. In this case, the documentation will have to express the functionality using more familiar terms — but these will generally be the terms of the older generation of tools — not abstractions of a generic purpose.

      But my general point is here, that we should address people in the vocabulary that they know and use, and that vocabulary, by and large, is the vocabulary of tools. To avoid using the user’s vocabulary merely because it happens to include the names of tools or features, is not part of task-oriented writing. The vocabulary of task-oriented writing is the vocabulary of tasks, and the vocabulary of tasks, by and large, is the vocabulary of tools.