How to Write a Technical Documentation Plan

如何编写技术文档计划

2020-04-14 21:40 clickhelp

本文共708个字,阅读需8分钟

阅读模式 切换至中文

There are strong reasons for having a documentation plan. The main one being - setting up a clear and open help authoring process. Creating a documentation plan means giving every team member an exhaustive reference point. The whole team will act within the guidelines of the plan and that ensures consistency and efficiency. Structure of a Documentation Plan There’s no strict rule defining how detailed the plan needs to be, but if you really want people to use it, make sure it is well-structured and easy-to-navigate. Do not overwhelm your technical writers - first of all this document should be easy to apply. How you structure it depends on specifics of your tasks, of course. It can be product-based, role-based, area-based. But there is a certain structure that is preserved in most of the successful documentation plans, we will talk about that in a bit. Also, we will provide you with the tips of what data to include in a documentation plan. A documentation plan is a bit like a user manual in itself, so you will find a lot of similarities with general technical writing. It should be logically structured. No need to go crazy and create a documentation plan for a documentation plan, but the least you can do is make sure the information is easy to find. For this, use your favorite navigation elements. We recommend using a TOC for sure. Cross-referencing, breadcrumbs, next/previous article links would be great, too, but it initially depends on the format you’ve chosen for the documentation plan. Some tech writers fit all the info inside one long document with a TOC being the primary means of navigation. This might work well for some, but we believe that creating a documentation plan using a help authoring tool just like you would do for any user manual works best. All the functionality like navigation elements is already there and you can apply your own best practices to documentation plan creation. Content of a Documentation Plan Since a documentation plan is also a way to align your goals with actions, it all starts with writing the goals and objectives of the project down. They are going to define everything that will be happening further on. No documentation plan can exist without a thorough content plan. It gives a great bird’s view of the user manual you are set to create. And, maybe, you will get ideas on how to improve it before the production starts. Of course, before starting a project, there are always time frames - this is the next important thing to include. When we have an understanding of what to do, it is time to mention the responsible people. Make this list detailed if you wish by explicitly describing roles and responsibilities. How these people communicate with each other and outer teams, what the processes are - should be added in the form of a workflow description. Now, it is time to define the tools and resources your team is going to use in the process. Add a list of software, websites, and services needed to fulfill the task. If you have a separate style guide, you can simply reference it. Or, add a section about design-related things like fonts and font families, colors, page layouts, picture sizes, etc. And, of course, don’t forget to mention what the result of all this work should be. This includes types of outputs, their formats. Anything you deem important can be included. You can set a desirable readability score for topics, average topic lengths, etc. While the core of a documentation plan should remain static, feel free to work on details if the reality dictates that some things should be added. Conclusion Having a documentation plan means standing on solid ground. Your entire team will have amazing reference material which is so helpful for a project of any size. Documentation plans are extremely helpful when you start something new or before a major iteration of a documentation project. Do you use documentation plans How detailed do you make them? Let us know in the comments below. Good luck with your technical writing! ClickHelp Team Author, host and deliver documentation across platforms and devices
制定文档计划是非常有必要的。 其中主要一点就是制定一个明确、公开的帮助创作流程。 创建文档计划意味着给每个团队成员一个详尽的参考。 整个团队将在计划的指导下行动,以确保一致性和高效性。 文档计划的结构 对于文档计划的详细程度,并没有严格的规定。但是,如果您真的想让用户使用它,那就确保它结构明晰,易于导航。 不要让技术作者不明所以——首先,这个文档应该易于应用。 当然,文档的结构取决于任务的具体情况。 文档结构可以是基于产品的,基于角色的或是基于领域的。 但是在大多数成功的文档计划中,都保留了一个特定的结构,我们稍后会讨论这一点。 此外,我们还将就文档计划中应包括哪些数据给出一些建议。 文档计划本身有点像用户手册,因此您会发现它与一般的技术写作有很多相似之处。 文档计划的结构应当逻辑明确。不用为此抓狂,为了写而写,但至少您可以确保信息易于查找。 为此,用您喜欢的导航元素。我们当然建议使用TOC(目录)。 交叉引用、面包屑导航、下一篇/上一篇文章链接也很好,但这首先取决于您为文档计划选择的格式。 一些技术作者把所有信息都放进一篇长长的文档中,并以TOC作为主要的导航工具。 这可能对某些人很有效,但我们认为,就像创建用户手册那样,使用帮助创作工具创建文档计划效果最好。 导航元素等所有功能都已经具备,您可以将自己的最佳实践应用到文档计划创建中。 文档计划的内容 创建文档计划是为了保证目标与行动的一致性,所以它从写下项目的目标就开始了, 这对于后续工作具有决定作用。 任何文档计划都离不开完整的内容计划。 对于您要创建的用户手册,它提供了一个很好的全局视角。 而且,也许您在生产开始之前会想到改进方法。 当然,开始一个项目之前,时间框架是必要的——这是下一个需要包括的重要内容。 当我们了解该做什么后,就该涉及负责人了。 如果您愿意,可以通过明确描述角色和职责来详细列出此表。相关人员如何与内部、外部团队沟通以及具体流程——这些应该以工作流描述的形式包括在列表中。 现在,是时候选择您的团队将在该过程中使用的工具和资源了。 在列表中添加完成任务所需的软件,网站和服务。 如果您有一个单独的风格指南,您可以作为参考。 您也可以添加一节设计相关的内容,比如字体和字体系列、颜色、页面布局和图片大小等。当然,不要忘记表明所有这些工作的输出应是什么,包括输出的类型及其格式。 任何您认为重要的东西都可以包括在内。 您可以为主题和平均主题长度等设置一个理想的可读性分数。虽然文档计划的核心应该保持不变,但是如果现实需要添加一些内容,您可以添加细节,无需顾虑。 结论 文档计划的存在意味团队拥有坚实的基础。您的整个团队将拥有大量参考资料,这对任何规模的项目都是非常有利。 当您开始新项目或者在文档项目的重大迭代之前,文档计划是非常有用的。 您使用文档计划吗?您制定得有多详细?请在下面的评论区中告诉我们。 祝您技术写作一切顺利! ClickHelp小组 跨平台和设备编写、存储和交付文档

以上中文文本为机器翻译,存在不同程度偏差和错误,请理解并参考英文原文阅读。

阅读原文