Maybe this is more obvious than I'm making it, but how do technical communicators reconcile the concept of "enough relevant information" with the basic value propositions of the long-tail?
Alan makes a great point here about productivity, necessity, and relevance. But doesn't Chris' basic premise (it seems like it was decades ago) argue that somewhere, someone will find that nugget of knowledge and be better off for it? The user who turns to the section of documentation that hasn't been accessed in five years is a user who needs information. The information is found, the task is completed, and the user is happy. Alan's argument assumes that there is some scale of value that technical communicators should consider when constructing and publishing an information product. If one user accesses a section of the documentation once every five years, Alan seems to argue that the section is not (necessarily) needed. One could save time and cost by simply not updating or including the infrequently used section.
And yet there is the obvious suggestion that one happy user is worth the time and cost to update the section. The information is only relevant when it's needed. Surely modern documentation techniques and technologies have made it possible for us to expand the amount of information we can include in our information products without dramatically increasing the time and cost to do so. Somewhere way back on the documentation tail is a tidbit of information that will one day make a user a happy (return) customer. A tough sell to the budget director, I know, but documentation always has been -- and will continue to be.
ADDENDUM: A case in point, although the comment about Macs having shipped with a thick book is pathetic because it assumes that the Mac is well-designed and user-friendly.
2 comments:
Hi Mike -
Thanks for the link back to my post on "Just Enough Documentation."
While I totally agree that it would be perfect if we could document everything just in case someone needs a particular piece of information at some unspecified point in the future, I don't think it's really practical.
Technical Documentation is invariably written in support of a product, and as such is assigned a timescale and a budget. In short it's as much a part of a business as engineering, marketing, sales, finance etc. And as such needs to be treated as a business asset.
In other words, like any other asset, a business owner wants to see a return for their investment. In the case of documentation that means investing time in the areas that will bring the most benefit to the most customers.
Alan, I completely agree, although upon re-reading my initial post, I see how my logic broke down and got a little whinny (crappy Monday writing).
I fully understand the difficulty we face proving a return on investments in product documentation. What I'm wondering is how we can use the basic premise of long-tail theory to IMPROVE our returns on investments in documentation. If we are to treat product documentation as a business asset, we should consider how to reconcile the documentation with all forms of asset capitalization. I've never tried to reconcile documentation costs with revenue in ways other than traditional product model/revenue point analyzes. I'm thinking it might be kind of fun to see what type of fiscal argument could be made for creating "the perfect" product documentation suite. Let's throw practical out the window just once and see what we come up with.
Post a Comment