We tech writers can learn a lot from neighboring disciplines and from people in other professions who address similar issues as we do.
For each post, I’ll first point out what it’s about and then explain why I find it relevant for technical communications.
So join me: Let’s shift our perspective and think outside the box for a moment. 🙂
Joe Shepley predicts on CMSWire how writing and maintaining documents will change over the next two years or so. He’s not talking about tech comm documentation, but business documents in general. They will change as social collaboration tools help us flee the “clunky trinity of shared drives, hard drives and email”. In his words:
- Some documents will no longer be documents at all
- Some documents will no longer begin their lives as documents
- Some documents will remain documents throughout their lifecycle, but how they get created and shared will change
– Of course, tech writers have been thinking for years now about formats other than documents, hence the discussions about wikis for documentation and about content strategy. I find Joe’s arguments relevant for these insights:
- Format should follow function. Choose the format that supports your content’s lifespan and frequency of change – and reader inclination, I would add for technical communications. Too often, I’ve had the format dictate how I write: I created Word documents, complete with title pages, table of contents and header and footer layout for internal communications. They would do just as well as wiki pages which are easier to create and modify, but still accountable thanks to history and rollback functions.
- Format can be fluid. The content needs to be reliable throughout the lifecycle, but the format can actually change. Tom Johnson explores this idea in more detail in his recent post Forum → Wiki → Blog Workflow.
Kathy Hanbury explains on the E3 Content Strategy blog how stakeholder interviews are important as you embark on implementing your content strategy. I’m summarizing those of her points that I find especially worthwhile:
- Interview stakeholders to establish credibility, to identify patterns and structures, and to find discrepancies and gaps
- Interview stakeholders who know the customers, the technology and the subject matter
- When you interview, be respectful of time, carefully craft your questions and take good notes
– For technical writers, interviewing developers or engineers, subject matter experts, as well as customers is an important skill. I appreciate Kathy’s post as a reminder of several points that I sometimes forget:
- Interviews are essential for quality and relevance of the documentation. And nothing can replace them, really, though customer surveys can come close if done well.
- Interviews are about covering all bases. Depending on organizational structure, tech writers have easy access to developers, engineers or whatever department they are assigned to. But documentation has stakeholders in other teams, too, for example in product management, customer service and training. Interviews can help you to ensure that your documentation is useful and balanced by addressing not only how the system works, but also how to use it efficiently and what it was designed to do.
To learn more from neighboring disciplines, see my post about “What tech writers can learn from UX designers“.
If you have picked up insights or lessons from other disciplines, feel free to leave comment!