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