The post got my thinking about how I write as a technical writer and my desire to better the UX for my readers. I too document Enterprise software (Adobe Connect and Adobe LiveCycle) in my current job. Also, I have never used casual language or humor. However, the rewrite of a warning, in Neal’s blog post, is enticing 🙂
I think a great way out, is to separate the two styles in to two different containers–official documents and semi-official or even informal blogs.
The humorous, casual, informal, witty, off-beat, and community content should be re-directed to the blogs! If they are done well, the blogs compliment the docs nicely. I am listing some advantages of blogging that come readily to my mind:
- One does not have to deal with the issue of localization of blogs. Blog content can be consumed by readers in their locales via Google Translate. Typically, organizations shy away from recommending that official documentation be read via Google Translate! This is not to suggest that humor gets translated–this post is just about blogs and documents. Irrespective of humor, via blogs we save localization costs.
- Blogs are not driven entirely by timelines or ties with lengthy review cycles or are a mandate. Blogs can be ad-hoc, personal blog posts can be published without internal reviews, and there can be both, lean periods and peak seasons, for blogging.
- Blogs also help in creating a good buzz about the software, in the community. This helps in indirect marketing. Blog posts can further feed into other social media channels like Twitter, Facebook, List.ly, Pinterest, and so on, to drive social media engagement.
- By re-purposing multiple blog posts, one can compile cheat sheet, tips and tricks, lengthier technical articles and workflows, and so on.
- On blogs one can invite community members to write–guests posts are a great way to give recognition to power users, as well as, have a vibrant community around a software. Exploring how other people use the same software leads to better self-learning as well.
- Many writers shy away and many a times editors do not permit documenting what do not work very well in the software. On blogs one can post actions that users should avoid, provide workarounds for broken workflows, share less-professionally done illustrations that cannot make it in the official docs, invite the community to share real-world workflows, etc. With timelines, styles guides, and localization costs driving documentation, it is difficult, if not impossible, to do all of these as part of documentation activities.
- With blogs one doesn’t need a user story! Not just technical writers but any member of engineering team who blogs, gets to be in touch with the real community, interact with the real users, face the real bugs, and get to know the real workflows.
Share in the comments, what are your reasons for blogging?
Updated Oct 23, 2013 to add last bullet point.
To allow for social collaboration and embedding of this content, I have re-purposed this blog post as a List at http://list.ly/list/DDo-why-should-technical-communicators-and-writers-blog.