As a lone writer, there is no one covering for you when you are out at the dentist or on a vacation. The developers, support engineers, and other product team members should be enabled to develop information when you are there and when you aren't. To keep these contributors going, you should have a set of guidelines that they use to produce, review, and submit that source content. Does this mean there is no need to define the processes that you use to take that raw information and turn it into the published documentation? Even though you know what you do and how you do it, there is still a need to document your writing and publishing processes -- that's right, document the documentation.
Why, you ask, do I need to document my processes when no one is going to do them while I am away? Well, there is always the "hit by a bus" scenario and another writer would need to quickly step in. In addition to the possibility of that statistically unlikely event, when you think through your process and write it out, you find its flaws and you improve it. And another plus, if you are a startup that will be seeking additional funding or a possible purchase in the future, having all of this together already will earn you more brownie points than you can imagine.
But first things first -- put the process and procedures in place so that the contributors (or SMEs, if you prefer) can start providing you with the source content that you absolutely need and then define and refine you own process and procedures for producing and publishing the documentation.
Whether you are in the office, working remotely, or out on vacation, you should have some procedures and guidelines in place for the people who create and review the source material for the documentation. This includes the format for the information, including text and graphics, as well as how to submit or post their contributions. If collaboration is part of the process, this process documentation should include how each contributor makes edits or comments to an existing document or file and how the workflow is managed (GitHub issues, Jira issues, or whatever you use). Consider what questions the contributors are likely to ask.
- How are new documentation needs tracked, assigned, and managed? -- Make sure to address how issues/tickets are created and how to define the criteria for new or updated content.
- How is content created? -- Make sure to provide clear procedures for how and where contributors can create new content so that it is ready for the review process.
- How are documents reviewed? -- Make sure to look through your review process, and if any part of that process involves you or any of your tools, you might want to evaluate how those tasks can be done by someone else. Even if your review documents are a bunch of Word files sitting in a shared directory, you can still document where it is and what to do with it.
The most important thing is to make sure that all of the likely contributors know where to find this information and that it's easy for them to understand. As a lone writer, your time is precious and you don't want to spend large amounts of it explaining these procedures and guidelines over and over again.
As your contributors use this guide to follow the outlined processes, you can figure out what works and what doesn't. Tweak and update this information as needed. When a potential contributor comes onboard, what they need to know is readily available and you won't be running yet another tutorial about contributing information or reviewing content.
As the lone writer, this is basically just you. But that might not always be the case. If you are at a startup or any other organization that has plans for growth, the day will hopefully come when there is another writer. And maybe later another. And so on. So whatever process and procedures that you put into place, you need to make sure that you address scalability. If you are currently stuck with something that clearly isn't scalable, such as writing a Word document and generating a PDF, make a plan for how to move away from that single-author paradigm. So in this sense, the writing process and procedure documentation will be an evolving artifact and would ideally include plans for how the process and procedures will move forward in that evolution. This will also be an ideal reference when the time comes to submit requests to management for new tools or additional writers.
In determining how your process will evolve, make sure that you consider the product roadmap. Develop your plans according to how you will need to accommodate the product itself. Is the product going to move to a cloud-hosted, SaaS model? If so, you had better start planning how you will move to a process that can produce hosted documentation that can be easily updated along with the product release cadence. Is the product going to include online help or links to documentation? If so, you should start figuring out how to manage these elements to fit into the UI development process.
If you’re far enough along in the process at your company and you’re regularly generating draft documents, it would be a great place to start by documenting the tools and processes you currently use to generate your documentation and where the source files and the generated documentation can be found. Next, you can start with some fairly basic style guidelines that include style decisions you have made and any external references that are to be used, such as the Chicago Manual of Style. And lastly, add any standards that you have established that are specific to your documentation set, such as how you reference product features or elements or what must be included on each topic or page of published documentation.
This does not need to be an overwhelming project that takes you away from your writing duties for a long period of time. Carve out an hour or two a week to make some progress. It won't be long before you have something that is far more comprehensive than you even imagined it would be, and it will be a great source when you are ready to add another writer and you have to produce a job description.
When you do need to make sure that the assembly line keeps moving along while you are out on vacation, figure out who might act as your proxy in terms of catching all of the documentation issues in the morning meeting and capturing new items in Jira or whatever tracking method you use. This might be the product owner, a developer, or a QA engineer that has been a constructive and thorough reviewer of documentation in the past.
The designated proxy will need to know what defines an issue or piece of content that needs to be documented, as well as the process you use for creating new tickets/issues. If you include this information in the contributor and/or writer guides, they can use this as a reference and really hold down the fort while you are away, and you don’t have a pile of emails that you need to input into Jira when you return.
While you’re away, developers will continue to produce new features and new design documents that will be incorporated into the overall documentation that you produce. The proxy can help ensure that these items are not forgotten while you are away, and the Contributor Guide that you produce will serve as a valuable resource to keep things on track.