Archive Page 2
From ops- to task-orientation
I asserted here that in my enterprise software experience, technical documentation often supplements the design and build process to address gaps that would be prohibitively expensive to address directly. The dominant human factors paradigm is that application user interfaces, or GUIs progress toward an ideal of flawlessly communicating the scope of the application, accurately modeling or enabling the various workflows and tasks, and providing absolute error-proofing.
I’ll leave it to others to chronicle and assess the advances made in the UI area; readers who remember when graphical UIs were novel can easily recall why the investment in explanatory writing was necessary, and why technical writing about enterprise software focused primarily on the operation of the system rather than on the tasks that users needed to accomplish.
It makes sense that early on, tech pubs resources were focused on helping users operate what were often very specific, non-intuitive, and unforgiving user interfaces. As these interfaces improved and became more standardized, task-oriented writing came into vogue, though many writing groups are to this day still struggling to adopt this approach.
At the same time that the focus of enterprise software documentation has evolved from operational to task-orientation, the delivery media and the tools used to create, manage, and publish content have also evolved, and trends in each of these areas have continuously influenced the others.
If task-oriented technical writing is now accepted as best practice, how does it relate to parallel developments and current best practices for tools and publishing media? What new tools and modes of delivery should tech pubs groups be looking at, how can they help to support or move beyond task-orientation, and toward what?
Filed under: Monetization, ROI | 2 Comments
Part of the product
My friend, colleague, and all-around stand-up guy, Jeff Gardiner comments that the issue of not being able to directly charge for product documentation “is complicated by the sense that documentation is not a part of the product”. This is particularly interesting given the trend in enterprise software away from physical “shrink-wrapped” packaging and toward the download model. In many cases, product downloads include and install documentation, but more documentation publishing is now going directly to corporate web sites, which has a number of advantages for tech pubs departments, but definitely loosens the connection between the ‘product’ and the ‘doc’ even further. I think this development represents a significant opportunity for tech pubs, for reasons that I’ll touch on here and explore in more detail in subsequent posts.
Jeff also points out that “Humans do very little without a verbal component involved. Most application usage takes place with a verbal soundtrack accompanying, even if that soundtrack is the silent internal monologue of the user…”, and goes on to point out the link between that interior monologue and the notion, which is becoming reality in some quarters, of incorporating collaboration with users into the product documentation process.
Collaboration on doc is a crucial development that I think helps clarify, and can even re-position, documentation within the user-assistance continuum; as Jeff points out, on on hand, collaborative doc will look more like support content in some ways, and it will also embed very valuable information about what customers want. As a tech pubs manager, it seems pretty obvious that being in a position to elicit, organize, consolidate, and distribute this kind of information back into the organization makes a clear case for ROI.
Jeff also refers back to Scott McNealy’s musings on self-explanatory applications that don’t require doc, and there are a number of ways one might respond to that; since I mentioned a user-assistance continuum earlier, I’ll stick with that perspective for now. It might be a valuable exercise to view any documentation requirement for an enterprise software product as a design defect – I would encourage it, but only as an exercise for the entire product team. They would discover pretty quickly that documentation fills a lot of crucial gaps that would be prohibitively expensive or technically impossible to address in the design and build. So then it’s back to the trade-off between engineering, doc, support, and training about how to piece together the complete user assistance picture: the classic quality vs. cost containment tug-of-war.
I happen to think that when the issue is quality vs. cost containment, tech pubs can easily hold its own in terms of quality, cost-effectiveness, and timeliness. But even so, I’d rather make that case while also being in a position to create and leverage direct relationships with users and systematically deliver that feedback throughout the product lifecycle.
Filed under: ROI | 1 Comment
As I stated in Charging for doc, most tech pubs groups can’t directly charge, or charge enough, for their products (the documentation and related content that they produce) to claim significant roi. Even so, tech pubs groups continue to get funded, and (typical enterprise software) products don’t get very far along before a resource is put to work on some form of ‘user documentation’.
For most projects, documentation commences without significant discussion of the reasons or goals; but the most common assumptions for documenting products include:
- Legal – documentation is required for sale
- User assistance – documentation adds value by assisting users and reducing support calls
These assumptions about the goals of product documentation fit squarely into the classic cost containment vs. quality tug-of-war: how much over the bare legal requirements should you invest, what is the value of doc’s contribution to ease-of-use, and how much should you spend on deflecting support calls?
Filed under: Monetization, ROI | 3 Comments
Charging for doc
Previously, I wrote about the relatively informal attitudes and approaches toward determining roi for technical publications. One thing I didn’t mention, possibly because it goes without saying, is that the overwhelming majority of companies can’t or don’t charge directly for technical content. In many cases, there are legal restrictions; sufficient documentation must be provided as part of the of the product.
Some companies (remember, my background is in enterprise software) have historically charged for additional supplemental or advanced content (typically more theoretical knowledge that is not directly related to product features and their use). Most often, these retail books programs are segregated from the mainstream of technical publications; since the authors are often not writers in the tech pubs group, and because both the number of titles and revenue is small (and usually shared with a third-party publisher), such programs are generally perceived as boutique operations, and not considered a major contributor to tech pubs roi.
Filed under: Monetization, ROI | 3 Comments
Companies that document their products always need to determine how much to invest in the process. Publishing requires people and systems to design, author, edit, format, brand and illustrate, and produce.
Once the books, help systems, web sites, etc. are created and distributed, their value is generally estimated subjectively; historically, it just hasn’t been easy or cheap enough to find out whether doing more, less, or different documentation would help or hurt a company overall.
In my experience, the process of determining the right level of investment in technical publications has generally been ad hoc, and influenced more by external factors, such as the culture of the company, the location of tech pubs within the organization (marketing, education, or R&D?), the savvy and charisma of the pubs dept management, etc. than by any concrete knowledge of what tech pubs contributes to the bottom line.
Granted, there have been more than a few projects aimed at proving or calculating roi for technical content, conducted by smart and talented people. I encourage those of you who have knowledge of specifics to respond to this post so we can follow up and share whatever insights emerge. But my point is that the data available on this topic don’t provide the same basis for decision-making as, say, the data that drives call center operations.
In the absence of available data with which to argue the value of tech pubs, budget decision-makers can safely rely on their own prejudices rather than substantive analysis. This state of affairs leads to a tension between between cost containment and quality, with the various tech pubs stakeholders engaged in a continuous tug-of-war over resources.
Filed under: Monetization, ROI | 1 Comment
Introduction
I’m Darryl Tewes, and I have been working in the technical communication / technical publications field since 1989. I have worked as a writer (captive and contract), a tech pubs manager, and most recently as the manager of a technical publications tools engineering group. Most of my experience has been in enterprise software.
This blog is mainly about the changing, or emerging, role of technical content and product information in the web 2.0 or participation era. I plan to set down my thoughts in a somewhat organized fashion, and I hope that they will stimulate productive and useful discussion. I don’t claim to be definitive, or to express the cutting edge or the last word on any subject raised here.
In talking about the role of technical content, I’ll probably also write a bit about the people, processes, and tools that create, store, manage, publish, and use this type information. While there are many interesting things to say about technical authoring, content management, audience analysis, etc., my focus will be on the business value of technical content and information products, and how individuals and organizations can recognize and increase that value.
Filed under: ROI | Leave a Comment
-
Recent Comments
darryltewes on Back in the saddle… milt brewster on Back in the saddle… Tracy Hickman on Renewed respect Jeff Stein on Renewed respect darryltewes on Talking tech pubs with JM …
