Document Development Life Cycle (DDLC) for Technical Writers

When you write documentation every day, you can’t help noticing that this process has phases and cycles that, in the majority of cases, are the same. They are called Document Development Life Cycle (DDLC).

Document Development Life Cycle (DDLC) is a systematic process of document creation that has a cyclic order.

Technical writers and content developers need to know DDLC as it allows to improve the quality of documentation, its precision, and delivery time. In other words, it is the unification of content writing steps to produce understandable content. DDLC has the following phases:

1. Analyzing and planning
2. Design
3. Content development and reviewing
4. Publishing
5. Maintenance

Further, we’ll discuss the phases of DDLC in detail.

Analyzing and Planning

This phase is vital. A technical writer is studying the requirements and the audience and, of course, collects relevant information about the product. The main questions at the moment are the following: Who is the audience? What and how should I tell them? It is high time to test a software product you are going to write about and talk to SMEs to get relevant information.

As for audience analysis, you need to know their level of technical knowledge. It is obvious that writing technical documentation for internal and external end-users is different. Surely, internal users have a better and deeper understanding of how this or that software product works, what features it has, and so on. But at the same time, they expect to get more complicated information that solves high-level problems. If you want to learn more about how to write for different audiences, check out our post – Targeting of Technical Documentation. You need to define the information gap and work out a clear strategy to eliminate it.

Sometimes, this phase includes the choice of tools to create documentation. Here is the list to consider:

• A help authoring tool. For instance, ClickHelp. There are companies that use Microsoft Word saying that it suits them best. It is really so if it is a small company with one or two technical writers. But as the company grows and develops its products, Microsoft Word is not enough to cope with the content development process. You need to analyze your needs. Some teams want a smart environment for collaboration, others want to make the review process easy and clear or to manage translations in the same tool. All that is possible with the right documentation tool.
• Tools for translation. If you need to translate your documentation, we recommend you choose a tool that will allow you both to write it and manage the translation process simultaneously. The latest Rainbow release of ClickHelp is exactly what you need in this case – you can easily create multi-language documentation sites, collaborate with translators, and keep track of the translation workflow.
• Tools for taking screenshots. Using visuals in software documentation is something natural. Make sure you know which tool to use and how. Read our post Taking Screenshots Right
  to improve your skills in taking screenshots.
• Diagramming tools. Sometimes, using diagrams is the best way of presenting the information. Embedding a diagram from a cloud diagramming tool into a topic, you get the greatest benefit ever: when you update the source, all the diagrams in all your docs update automatically. That saves you from making mistakes and spares time. Have a look at our post about using diagrams and diagraming tools – Using Diagrams in IT Documentation: Best Practices.
• Screencasting and video capture software. That’s one of the latest trends to insert videos in online documentation, and it shows great results: documentation becomes clear, and readers enjoy it. Our post – Latest Tips on Using Video Content in Technical Documentation – will tell you why you should use videos and screencasts in help docs and how to choose tools.

Design

At this phase, a technical writer needs to choose what technical documentation will look like and how the content should be presented. First, one should single out the logical structure: the whole information should be divided into interrelated blocks. The structure mostly depends on the type of product. Actually, this phase deals a lot with information architecture as the way a tech writer presents the information should be tailored specifically for the target audience. The main idea is to provide a smooth user experience. At this phase, a tech writer or a content developer should make up their mind what visuals are most suitable and what they should illustrate.

Moreover, to create trustworthy technical documentation, one should pay attention to its branding. It is vital to use logos, corporate colors, and fonts. All that makes documentation look professional and makes you different from competitors. If you want some more information about branding, take a look at this post – Technical Documentation Branding – What for?

Content Development and Reviewing

Now a technical writer finally starts doing what they enjoy most – writing. When you have a plan, a strategy, and enough information about the product, that won’t take much time to write everything down. As a rule, reviewing and editing take far more time. How to make your life easier? The answer is simple: choose a technical writing tool that will make collaboration simple and offer a clear review process. The best solution is to use a SaaS (software-as-a-service) tool. It will allow a team of tech writers and reviewers to work remotely without losing the latest version of a topic and comments.

Publishing

The best option is to publish technical documentation online. At the moment, people seldom use printed versions. Online documentation has many advantages:

• Accessibility. Online documentation is available 24/7. You can use both your laptop and smartphone to read it.
• Easy maintenance. When online documentation is updated, all the end-users get access to the relevant information right away. This is not the case with PDF files or printed manuals – vendors cannot be 100% sure that a user has got the new instruction.
• Case deflection. If users can find the information themselves, they prefer not to reach out to the support team.
• Contributes to sales. If online documentation is public, potential users can find answers to their questions. That helps the audience get acquainted with a product.
• Can be a marketing tool. Documents that are meant for public use, surely, contain keywords that will improve their visibility. They may attract the attention of potential customers.
• Restricted access to sensitive information. Some documents are meant for a particular type of user. You can easily create password-protected online docs. No other user will access them. Read more about password-protected documents in our post Should You Restrict Access to Your Online User Guides?

Maintenance

Products update rapidly, and documentation should be updated as well. It happens when a software product has a new release, for example. As a rule, there are a lot of topics for the update, there is very little time, and there is a lack of human resources. In this case, you can update topics step by step. Use online documentation reports and statistics to figure out the most and least popular topics. At first, update the most popular ones. Later on, you can work on the rest of the topics. It means that you need to use convenient mechanisms of partial topics update, which can be offered by SaaS technical writing tools.

Some types of documentation require regular updating because the processes they describe change regularly. In this case, it is better to create a plan of updates and work according to it.

Conclusion

Document Development Life Cycle is a complete life cycle of documentation. Getting acquainted with its peculiarities, a technical writer may succeed in creating awesome docs for all types of end-users. My piece of advice here is to use a help authoring tool that can maintain this process from the beginning to the end.

Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices