Notes from Future of Technical Communication Webinar
Larry Kunz's recent webinar, The Future of Technical Communication, is one of the best webinars I've listened to recently. Larry's message is not only on target and insightful, he also articulates concepts in a clear, organized way. It's easy to listen to and you'll get a ton of useful information out of it.
Larry mentioned several trends in tech comm and then several skills tech writers can develop to meet those trends. The following are a few brief notes from points he mentioned.
Trends in tech comm
- Emotional experience: Building trust & confidence, encouraging community; communicating in a more personal way
- Collaboration: Working with lots of different people on content; origination is not just with tech comm
- Mobile delivery: Creating adaptive and responsive content that adjusts to mobile devices (not just style but also navigation)
- Content strategy: Following a strategy for all phases of your content's lifecycle; planning, controlling, maintaining, removing content in alignment with business goals
- Agile pace: Keeping up publishing velocity to match information needs and software releases
Skills to develop
- Develop business know-how to make a case that speaks to cost revenue or avoidance
- Understand concept strategy and how you fit into the picture
- Know structured authoring
- Understand information architecture
- Improve ways of working to fit the following:
- Publish in shorter, more focused dev cycles
- Use tools that support collaborative & structured authoring
- Work in globally distributed teams
- Create content good enough to ship (not perfect)
- Make lateral interactions within the company (crossing department boundaries)
Complementary blog posts
Larry has a series of blog posts covering the same information as the webinar. See the following:
- #techcomm trends: Technical writing as an emotional experience
- #techcomm trends:Going mobile
- #techcomm trends:Content as a business asset
- #techcomm trends:Breaking down barriers
- #techcomm trends:Good, not perfect
My thoughts
What struck me most were the points about collaboration, agile publishing, and creating content good enough to ship. In my experience, ramping up the publishing velocity is both challenging and essential. I'm not just talking about keeping pace with new features released in a two-week agile sprint, but also creating documentation to address the endless number of incoming support cases, forums, and other channels where users interact.
It seems that users today are much more accustomed to interacting online, providing feedback, asking questions, etc., and expecting quick responses. Support teams quickly create content to close incoming cases, but much of that information needs to integrate into the documentation in an easily findable way to reduce future support cases about the same issues.
Strategies for publishing velocity
I think the only way to match the expected publishing velocity is to accept a few principles:
- Content doesn't need to be perfect, just good enough to ship. So there's a typo here and there. That's okay. Readers are scanning the content in 5 seconds anyway to see if it answers their question. Also, published web content isn't unchangeable -- you can always update it later.
- Tag content instead of arranging it in a table of contents. It seems like figuring out where content fits into a TOC is too tedious and slow. Instead, if you can just tag content with the right metadata and plug it into the system, you can push content out faster and more efficiently.
- Allow others to publish. Allowing people outside of tech pubs people to author and publish content -- even in a semi-illiterate way -- seems like a necessity in order to keep up. The idea that a small tech pubs (outsiders to the actual business scenarios) group can handle all the information needs and perspectives of a large organization and even larger community base is a farfetched idea. Instead we need to help SMEs understand the right tags to use, equip them with tools that won't result in poor content (e.g., maybe use Markdown instead of the rich text editor), and then simply make quick editorial passes to their content after it's already online.
