The Degentrification of User Assistance

A theme I have watched for awhile has finally caught up to me. There has been a steady movement away from using professional technical writers to produce user assistance and, instead, let subject matter experts do it directly.

Some examples:

• Wikipedia (I use it all the time to understand security concepts my products naturally assume I already know.)
• Product-sponsored social networks that let users pose questions to product experts or other users
• Open social networks where users pose questions for other users in the audience, e.g., Twitter and Linkedin

I am working on a project now to revamp an Internet portal for managed security services. There is a  requirement in the project to provide contextual help at the page level. But there are no technical writers. To date, there has been no formal approach to user assistance, and this particular portal offers a varied set of documents available to users. There are PDF mini-papers, PDF user guides, HTML help for some pages, Knowledge Base Articles that are available to the public, and video tutorials and best practices documents provided by a training group.

And there was a strong sentiment among the project stakeholders to have SMEs write the content directly without having to require engineering intervention to post new topics or edits to existing topics.

As someone who still feels he is a technical writer at heart, my initial reaction was mixed. On one page our current online explanation reads, "This report is ran every hour." Ouch. Also, last year I pulled in user guides from a third party vendor where none of the procedures had numbered steps. Yes, this is what happens when you let untrained writers generate unedited content.

But let's remember Sturgeon's law: "Ninety per cent of everything is crud."

The truth is that in those examples above, there was also some very useful information--just badly written. On the other hand, take a look at professionally written Help and you will find your share of well-stated, correctly punctuated crud. "Type your user ID in the field labeled UserID." Well said but still crud!

My job right now as the UX architect on the project is to translate these high level requirements into scenarios and the starts of stories so that my Engineering cohorts can estimate the various features. So with apologies to my technical writer friends, I have embarked on creating a design that will make it easy for SMEs, who have insight about how to get value out of our portal and services, to pass that insight along. I want it to be easy for the SME to post, and easy for the user to get to it.

So I'm looking at a split pane, embedded assistance panel. The top pane will be for tips and definitions and the bottom pane will be for links to larger files, such as video tutorials and PDF documents that offer more extensive information. It can also contain links to KBAs as well. The split pane approach keeps the external links above the fold.

I'm asking the Engineers to code it to look for HTML files in a database, and to make that database available to the SMEs who are responsible for the content.

So not only I am developing user stories such as:

• As a portal user, I want to see contextual Help so that I understand how to use specific aspects of a screen I am on.
• As a portal user, I want to hide the embedded Help pane so that I have more real estate on my screen.

I am also developing stories such as:

• As an SME, I want to upload content to the embedded Help for a specific screen so that I do not have to be limited by engineering availability to add or edit content.
• As an SME, I want to provide links to documentation and media that could help a user on a specific screen so that I do not have to be limited by engineering availability to add or edit content.

In addition, I will develop the templates and CSS files for the embedded panes along with guidelines that help SMEs focus on writing effective user assistance.

Not sure what the outcome will be, but I suspect it will be Help that is more helpful but less elegant than if we went with a traditional HAT and technical writing staff. I'm sure there will be examples aplenty that support Sturgeons law, but that is always the case.