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
-
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 …
Darryl, I’ve enjoyed reading your blog posts. Here’s my two cents on this topic:
Though the emphasis on creating “intuitive” GUIs is a noble one, very few companies, such as Intuit, get it right. I believe the success of a GUI is more tied to the simplicity of the underlying system than heroic interface engineering. Compared to configuring a database or a CRM application, preparing your taxes or balancing your checkbook are reasonably simple tasks with well-defined and understood parameters. Systems with complex operational characteristics require an understanding of the overall scope of the system and often have horribly mangled GUIs. I can recall one project where configuration could be done using either SQL or by means of a GUI. I could explain the SQL configuration in about 4 pages, whereas it took me about 30 pages to describe the GUI configuration.
Most companies now have “UI engineers,” who are chartered with bringing structure to the GUI. This is great, but the success of their efforts depends on how well they mesh with the engineering teams. If the complexity of a system is exposed to users, it’s very unlikely any amount of GUI magic will make a user’s tasks any easier. The documentation effort is the last link in the “usability chain.” In my experience, documenting complex system requires users to understand the overall context in which their tasks are performed. The best documentation for these types of systems provides users with the navigational ability to locate the relevant conceptual topics from the task topics, and vise versa.
Hey Gordon – thanks for reading! I agree with your points; the domain and task boundaries for a given UI are definitely major factors for usability. A lot of software apps these days take a toolkit approach that trades flexibility for ease of use. For these types of products, context-sensitive help is often constrained, since it’s not easy to infer much about what users are trying to accomplish simply from the screen or field they happen to be using – so the help ends up just explaining the UI itself, which is less desirable as UI features and behavior becomes more standardized… For this reason, I predict a decline in successfully promoting tech writers as usability experts – I think that our claim to adding great value in the usability area has sort of run out of steam, unfortunately…