DDLC phases in technical writing explained

In this article, I cover each of its phases (or steps or stages) in DDLC (document development lifecycle) in detail. It is important to understand how the phases flow into each other and which resources or tools come into play in each phase. Each of the phases in DDLC requires inputs and produces outputs.

Therefore, I will use the ITTO concept (inputs, tools and techniques, outputs) from PMI’s project management techniques to explain DDLC phases in technical writing.

Note: I have introduced DDLC in a separate article. This article dives directly into the phases of DDLC. Be sure to check it out to better understand the concepts in this article. Ready? Let’s begin.

What are the phases of DDLC?

There are six phases of DDLC. I have covered them briefly in a separate article, but here they are:

1. Analyze
2. Design
3. Develop
4. Review
5. Deploy
6. Maintain

Generally, these phases are sequential without overlap. However, in some cases, for smaller-scale projects, some of the phases do overlap. For example, development and review can take place in tandem.

Let’s look at each DDLC phase, along with the actions a technical writer performs in each phase, in detail.

DDLC Phase 1: Analyze

The primary phase. Phase-uno. The understanding derived in this phase of the DDLC determines how thorough or complete your documentation will be.

This is typically your first experience with the product or topic. In this phase, you develop an understanding of the product or topic.

In my experience, this phase takes a major chunk of your time. A technical writer’s job is 60% analysis and research, 35% writing, and 5% rewriting based on reviews.

You review existing documentation, if any, and conduct interviews with subject matter experts (SMEs). If this is the first document for the product or topic, you also go through knowledge transfer sessions and demonstrations to understand the product or feature.

Existing documentation comes in two forms:

• Design or spike documents created by the SMEs when designing the product or gathering user requirements. Examples of such documents include user requirements documents (URD), business requirements documents (BRD), system requirements documents (SRS), detailed design documents (DDD), and functional specifications documents (FSD).
• End-user documentation, created either by an SME or another technical writer.
  More often than not, the design documents either do not exist or are outdated since the product likely went through a few design changes. So do not rely completely upon them.

Aside from going through the existing documentation, you also conduct your research about the product or topic, the technology on which it is based, and the typical end-user.

Understanding the end-user (your target audience) is very important as it determines the level of detail that will go into your documentation. It also determines the case studies or scenarios you will need to capture in your documentation.

Inputs

• Design or spike documents
• Business or user requirements documents
• Product demos
• SME interviews and knowledge transfer sessions

Tools and techniques

• Document research
• Knowledge transfer sessions
• SME interviews
• Product technology research

Output

You don’t necessarily have to create any document. Still, generally, you make notes of everything you have gathered from the subject matter experts (SME) during your interviews and knowledge transfer sessions.

The industry term for these “notes” is Understanding Document (UD). In my experience as a trainer and mentor to technical writers, I have always opined on using UDs. That said, I have not seen the practice of creating UDs in most organizations, but it is a good practice to have one.

Pro tip: Get the UDs checked by the SMEs to ensure that you have understood everything clearly and accurately. You may also schedule more interviews as needed.

DDLC Phase 2: Design

Based on what you have understood about the product or requirements, you decide on the following key elements of document design:

• The document type. User guide, troubleshooting guide, configuration guide, etc.
• The format of the document. Presentation style, doc style, video or text-based, etc.
• The manner of deployment. Publish online, printed version, book format, etc.

When you are satisfied with the design, you propose to project stakeholders with your recommendations. You modify the design based on their feedback and proceed to the next phase of the DDLC. This is especially useful when creating the first document or first major document for the product or topic.

Stakeholder feedback at this stage also gives you the necessary inputs to create document templates as the feedback provides you an insight into how they plan to use the document.

Input

Understanding document

Tools and techniques

Discussions with SMEs

Output

A formal proposal to project stakeholders.

Pro tip: In most cases, if the topic is minor, you do not need a formal proposal and approval. However, some organizations prefer that every piece of content go through a rigorous review and approval process. So, in such cases, a formal proposal can save a lot of time and rework later.

DDLC Phase 3: Develop

You start creating the content in this phase. Ideally, by the time you reach this phase, you will have a good understanding of the product and all the necessary access to the product and associated systems. I mention product access here because you need to use the product yourself for capturing scenarios and screenshots.

A necessary detour here. Lazy technical writers avoid using the product or module themselves and instead depend on the SMEs for material such as screenshots.

Screenshots shared by SMEs are not always usable because they might not be in the proper resolution, show confidential or random gibberish data, etc. So, create the screenshots yourself using your own test data set.

Besides, using the product gives you invaluable hands-on experience that adds to the documentation’s value and eventually reduces your dependence on SMEs.

After you finish creating the content, ensure that you do a thorough self-review before moving to the next phase.

Self-review will help you:

• Catch typos and grammatical errors.
• Improve the content. Make it tighter.

Inputs

• SME interviews and discussions
• UD notes

Tools and techniques

• Content authoring tools to create the content. For example, MS Word, LibreOffice, etc.
• Image or video editing tools to capture and edit images, if any. For example, SnagIt.
• Style guides to ensure a consistent style of writing throughout the document.
• Grammar and spell-check tools like Grammarly.

Output

The first draft of the content. Ready for review.

DDLC Phase 4: Review

Get a final sign-off from project stakeholders after creating the content. This sign-off implies that the document is ready to be deployed for use. This sign-off takes the form of a review.

Typically, the SME you have been coordinating with reviews your document to ensure accuracy. In other cases, project stakeholders such as project managers and product owners also participate in reviews. This is critical, especially in technology-heavy documentation.

You might have to rework the content based on the review feedback. Initially, you might also go through multiple rewrites before your content is approved. The Review phase is perhaps the only one in which the document cannot proceed to the next phase without receiving the necessary approvals.

Pro Tip: As a beginner, never skip document reviews. Mistakes or inaccuracies caught by the SME become essential lessons for you for subsequent documentation tasks. Editor reviews are also required In organizations with an established content style guideline Editors look at the documentation from a language and style consistency perspective. Their feedback is also very helpful in improving the quality of your work and style of writing.

Inputs

The first draft of the content.

Tools and techniques

• Manual self-review or automated review using editing software.
• SME review for accuracy
• Peer or editor review for style guide compliance

Outputs

An edited or reviewed version of your document.

DDLC Phase 5: Deploy or publish

After you have received the final approval from the SMEs and editors, you publish the document. You could publish it in your team’s cloud storage, SharePoint, email PDFs to the product owner, or make the content live in your CMS. The deployment method has been decided in the Analyze or Design phase, deployment usually does not take time and you can finally take a breather with some coffee!

Input

The approved document or content.

Tools and techniques

Whichever CMS or mode of deployment is preferred by the project stakeholder.

Output

• The published documentation.
• The published content

DDLC Phase 6: Maintain

After the document is published or deployed, maintenance becomes a continuous phase. Be it keeping the document updated based on the latest updates to its topic or improving its content.

As the document’s owner, you must keep the content updated. There might be enhancements or bug fixes that impact your document. Even if there are none, updating the document as and when you discover any nuances is a good practice. As your experience with the product grows, you will be able to identify areas of improvement in your documentation.

Typically, you submit the document for review again after making any updates. But, you can forego the review if you made a minor change such as correcting a typo or rephrasing a sentence. However, ensure that you update the document’s version history with the changes you made.

Inputs

• Update requests
• Document bugs
• Identified enhancements based on self-review

Tools and techniques

• Content authoring tools to create the content. For example, MS Word, LibreOffice, etc.
• Image or video editing tools to capture and edit images, if any. For example, SnagIt.
• Style guides to ensure a consistent style of writing throughout the document.
• Grammar and spell-check tools. For example, MS Word’s in-built grammar check, or Grammarly.

Output

Updated content

Conclusion

• There are six phases or steps in DDLC: Analyze, Design, Develop, Review, Deploy, and Maintain.
• Following and understanding each of the steps or phases in the DDLC is important.
• Each phase or step in the DDLC has its own set of inputs, tools, techniques, and outputs.
• As a beginner or an entry-level technical writer, learn each phase in the DDLC well. They are one of the most frequently asked questions in job interviews.

The following table shows the ITTO model for the DDLC phases:

I hope you found this article helpful. If you didn’t, then I would love to hear from you about what I can do to improve it. For more technical writing-related articles and resources, see the Technical Writing page. Also consider following my YouTube channel learntechnicalwriting, Reddit community r/learntechnicalwriting and Quora space Technical Writer | Technical Writing for more such content.