If you develop customized projects for your clients, you know how important it is to put your experience to good use to avoid starting from scratch every time, even if each project is unique.<\/p>\n
But if you provide clients with documentation, how do you make sure it\u2019s both unique and adapted to each project, without having to reinvent the wheel?
\n![\"\"](\"https:\/\/lios.dev.creationsunivers.net\/wp-content\/uploads\/2018\/07\/lios-doc-sur-mesure-juin2018-v1.png\")
\nTo efficiently produce unique, quality documentation for each project, proper preparation is key. As you work on a first project, consider your future project needs; some content will be common across the board. Take the time to develop a sound project structure and to implement a few basic elements, which will help you in other project documentation.<\/p>\n
There are probably some sections of your documentation that apply to all of your products. Your contact information, say. Or maybe your warranty, specific security advisory or user guidelines. Thanks to content management tools<\/strong>, you can create common content and input it easily in various manuals and online support tools. Some of the functionalities available (variables, conditions, and so on) allow you to produce personalized content from common content in the blink of an eye. Tools like MadCap Flare or Adobe RoboHelp also offer a number of formatting options. From a single source, it\u2019s possible to generate a Word or PDF document, or even online help in HTML format, to meet all your clients\u2019 needs.<\/p>\n These tools are also extremely useful for translation management: once content in the manual has been translated, it is automatically retrieved to be reused in subsequent manuals\u2014a great way to save time and to reduce costs!<\/p>\n If all your projects are similar, your documentation should generally convey more or less the same type of information. The best way to make sure you have all the information you will need to generate project documentation is to create a checklist<\/strong> of the various components required.<\/p>\n This list obviously varies from one business to another, and by project and product, but it should define what your writers require. A checklist might include:<\/p>\n You should develop this list when you produce the documentation for your first project, trying to predict what components will be crucial each time. Make sure to update this checklist regularly as you go on to work on other projects: your checklist will become increasingly specific and complete over time.<\/p>\n Whether you\u2019re producing internal documents or dealing with a subcontractor, take the time to define your main project and product terminology. Don\u2019t hesitate to ask for employees\u2019 input; their contribution is the best way to make sure they\u2019re comfortable with the terminology, and therefore more likely to adopt it. Don\u2019t forget that the term base<\/strong> should be updated continuously to accurately reflect your company and your products. An accurate working lexicon will ensure that everyone\u2019s speaking the same language, from one project and one document to the next.<\/p>\n It\u2019s also worthwhile to get your terminology translated into all the languages used in your documentation; this will help immeasurably in any document translation and will guarantee that the terms used are always the same, even if you deal with different translators.<\/p>\n Your projects are probably overseen by different project managers, not all of whom will be good at communicating with writers. Help guide them by creating a workflow that outlines the main steps and each person\u2019s role at each stage. This protocol should also indicate what inputs are required at each point in the process. For instance, a workflow might clearly establish who is responsible for answering writers\u2019 questions, editing and signing off on a document. If your documentation consists of online support, you may also note the points at which user experience testing should be carried out and by whom.<\/p>\n As with your checklist, a workflow should be updated and evolve to become as efficient as possible.<\/p>\n Ideally, just one person would be responsible internally for producing documentation, even in cases involving subcontractors. A product documentation manager<\/strong> is in some ways the liaison between project partners and subcontractors. Make sure to choose someone who is familiar with the various teams at work on a project, who knows who can provide a missing piece of information, and who is best suited to edit or approve content. It goes without saying that the documentation manager must have dedicated project management time.<\/p>\n When you assign someone to supervise all the documents you produce, you\u2019re also sure of your documentation as a whole. This will help you provide all your customers with a consistently good user experience.<\/p>\n Because there are often a number of different project coordinators, a communication tool<\/strong> that centralizes all exchanges can be useful, especially when several projects are on the go at the same time or if several project coordinators require the same information. The answer to a question for one project might also serve other projects. There are numerous communication tools available (Slack, Stride, Asana, etc.). All you need to do is find the one that\u2019s best for you!<\/p>\n","protected":false},"excerpt":{"rendered":" If you develop customized projects for your clients, you know how important it is to put your experience to good use to avoid starting from scratch every time, even if each project is unique. But if you provide clients with documentation, how do you make sure it\u2019s both unique and adapted to each project, without […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[32,23],"tags":[],"class_list":["post-422","post","type-post","status-publish","format-standard","hentry","category-content-management","category-technical-writing-and-documentation"],"acf":[],"_links":{"self":[{"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/posts\/422","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/comments?post=422"}],"version-history":[{"count":0,"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/posts\/422\/revisions"}],"wp:attachment":[{"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/media?parent=422"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/categories?post=422"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lios.dev.creationsunivers.net\/en\/wp-json\/wp\/v2\/tags?post=422"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Checklist<\/h4>\n
\n
Term base<\/h4>\n
Workflow<\/h4>\n
A documentation manager for all projects<\/h4>\n
A communication tool<\/h4>\n