As a follow-up to my last post, When Help Content Is Forgotten, my colleague pointed out that having a set of agreed-upon best practices for technical writers is one of the first steps in establishing traction with project managers. Otherwise, project managers can resist or dismiss a technical writer’s recommendations as subjective opinion.
In an effort to be concise, here’s my stab at the ten things project managers should know when working with technical writers. Imagine formatting these ten sentences in a neat little card that you periodically email to project managers, or that you give project managers when meeting them for the first time. I made them concise so that they’ll be read. These are the 10 concepts that all project managers should know about help content.
10 Best Practices for Help Content
- Allocate budget for help content in your project plan.
- After your project is approved, contact a technical writer about deadlines for deliverables.
- Recognize that what seems intuitive to you may be unintuitive to users.
- Technical writers need access to test environments, prototypes, and dummy data.
- The user interface is driven by text, so involve a technical writer’s language expertise with prototypes.
- Because help content is part of the user experience, technical writers work closely with interaction designers.
- Expect short guides and visual content rather than long manuals.
- If collaboration and distributed ownership are important, consider a wiki platform.
- Technical writers are your application’s first users — their feedback can improve usability.
- Documentation isn’t finished with the application’s release, but continues as users submit feedback.