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.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.