Lead Writer: Kieran Morgan | Peer Reviewer/s: Steve Moss | Managing Editor: Kieran Morgan

This chapter focuses on the customization of the Technical Writing Process to suit specific project needs and organizational contexts. It outlines a practical, iterative approach to adapting this process, one that emphasizes the importance of understanding an organization’s unique requirements and modifies the process accordingly. The chapter also includes case studies demonstrating the application of this tailored process in different organizational settings and providing practical examples of its flexibility and adaptability.

Who Should Read This
• Aspiring Technical Writers • Beginner Technical Writers • Career Advancers • Managers of Technical Writers • Educators of Technical Writers • Cross-Domain Professionals • Consultants
Table of Contents: Technical Writing Process
Previous: Chapter 6: Career Flexibility in Technical Writing	Next: Chapter 8: Artificial Intelligence (AI) for Technical Writers
Table of Contents: Project Management for Technical Writers
Previous: Coming soon!	Next: Coming soon!

1. Introduction

If you scan this book’s table of contents, you’ll notice how it’s structured around eight core phases: Plan, Design, Write, Edit, Review, Translate, Publish, and Manage. These represent the backbone of the Technical Writing Process: the macro steps that writers such as yourself carry out when crafting technical documentation.

But it’s more than that. The process is a learning tool that weaves in concepts relevant to the practice in each chapter. Think of the Technical Writing Process as your roadmap to your craft. You can use it as a learning tool to build your knowledge of the fundamentals of our profession or as a practical tool to apply your knowledge in the real world.

In this chapter, we’ll take a practitioner’s view. We’ll give you a bird’s-eye perspective of this practical process, why it’s so important, and how to customize it to suit your writing projects.

2. [Theory] The Technical Writing Process

The Technical Writing Process defines the eight core steps in technical writing projects: large or small, complex or straightforward. The steps aren’t strictly sequential; in practice, there are plenty of loop-backs and decision points that lead to alternate routes through the process. Much of this iterative nature occurs in the write-review-update cycle, which we discuss in Chapter 19: Write Draft > [Theory] The Write Review Update Cycle.

So why present a sequential view if it’s not strictly true? First, every project is slightly different—the high-level view of the Technical Writing Process encompasses the flexibility to accommodate this. Second, the simplified view helps you understand the big picture before you develop a deeper understanding of the myriad ways it can be applied in practice. All in all, it’s a much easier way to comprehend the vast breadth of technical writing—and internalize the process as your mental roadmap—before you immerse yourself in the possibilities and nuances of application.

You’ll notice that the process is divided into several sections:

• Phases: These are the macro steps of the Technical Writing Process under which everything is organized: Plan, Design, Write, Edit, Review, Translate, Publish, and Manage.
• Activities: These are the high-level steps that support each phase. In this book, roughly speaking, each activity equates to a chapter—except in the Publish phase, where we get a little more granular. These chapters are where we discuss the theories and detailed steps, showcase examples, and provide templates to equip you with the knowledge, skills, and tools to excel at your job.
• Outputs: These are the deliverables created as a result of executing each phase and activity. In the chapters of this book, we explain in detail how the outputs are a result of the practical steps and provide links to templates or samples you can use to create them.

What Does That Mean?

Deliverable The output of an activity in a process or project. In technical writing, deliverables include user guides, manuals, and procedures—that is, content intended for use by end-users—as well as internal documents, such as Documentation Plans and Schedules, that are used in project planning and management. Activity A task, action, or milestone in a process or schedule. In technical writing, as in process analysis, activities are commonly expressed as verb-noun phrases—”define scope,” “write first draft,” and so on. Process A set of activities or tasks performed to accomplish an objective. Processes typically have a trigger that initiates the process; inputs necessary to perform the process; a corresponding result, or output; and a sequence of steps and decision points in between.

Note

Some Templates Are for Subscribers Only Some of the templates in this book are for subscribers only. You’ll need to subscribe to our online knowledge base at https://boffin.education/ to access them in editable format. to access them in editable format. Subscribers to the e-book and paperback versions of this book can use the discount code in Templates to obtain a free one-year subscription and access the full breadth of our technical writing content. If you don’t want to subscribe, head over to our website. There you’ll find many of the more straightforward templates available for free, and others are presented in a noneditable format as images.

2.1. Why Use the Process?

The Technical Writing Process is a highly practical, off-the-shelf methodology that can be customized and applied to any writing project, large or small. But it isn’t just a toolkit—by marrying up the relevant theories that support each practical step, you can build your knowledge of your craft, as well as apply it in the real world.

Here are some benefits of using the process:

• Time Efficiency: The Technical Writing Process offers a ready-to-use framework that can potentially save hundreds of hours that would otherwise be spent in developing methodologies and tools from scratch.
• Audience Focus: This approach emphasizes the importance of understanding and addressing the specific needs of the audience, ensuring that the documentation meets their requirements.
• Accessibility: The book is designed to be easily understandable for newcomers and nonwriters. It explains technical concepts clearly and includes infographics for better comprehension.
• Predictability: By turning technical writing into a defined and manageable process, the Technical Writing Process reduces the reliance on ad hoc methods, increasing the predictability of project outcomes.
• Consistency: It provides a standardized method for content development that ensures uniformity across teams of technical writers, which aids managers in implementing consistent practices.
• Planning Tool: The process serves as a comprehensive guide for project managers. It helps to schedule and execute documentation projects by outlining high-level phases, outputs, and detailed activities.
• Collective Wisdom: The book is based on the experiences of its writers and includes insights and suggestions from a wide range of experts and seasoned writers, drawing from a wellspring of collective wisdom.

Introducing the process comes at an upfront cost—such as investing time in planning, and a more rigorous and structured way of working. However, the benefits of adding structure will quickly become apparent, as your projects produce better quality deliverables in a more consistent fashion.

Insight

Measuring the Benefits Technical writers often find that everyone wants the highest-quality content in the shortest amount of time. The art of technical writing is to do so in a way that creates the maximum value with the minimum of wasted effort and inconvenience to others. This is what the Technical Writing Process was designed for. Better yet, you can prove it with data! Consult our forthcoming book, Technical Documentation Management—available online at https://boffin.education/category/technical-writing/technical-writing-books/—for guidance on how to quantify the value and measure the success of your documentation projects.

2.2. What Documents Does the Process Apply To?

The Technical Writing Process applies to any type of document written by technical writers in print or digital format. These are discussed in detail in Chapter 2: Roles and Responsibilities > The Docs They Write. However, the principles in this book can be applied to virtually any project where the primary deliverable is documents (information).

What Does That Mean?

Information Data that has been processed and organized to support decision-making; for example, a document. Remember it as data “in formation.” Document A discrete unit of information used to guide work, decisions, or judgment that serves as a guide to what should be done. Documents are forward-looking, as opposed to records, which are historical. Examples include technical documentation, plans, policies, and engineering drawings.

3. [Theory] Comparing Information Development Frameworks

The Technical Writing Process is a high-level, sequential framework for developing information that has been specifically tailored for technical writing. JoAnn Hackos defines a similar process for developing information.¹ These different depictions aren’t incompatible; on the contrary, they’re well-aligned, albeit differently nuanced, perspectives.

Where they differ is in the details, such as phase names, which activities are included in each phase, the names of the outputs for each phase, and so on. For example, we’ve split Manage and Translate into separate phases in our process. In Hackos’s model, these are intertwined throughout the other phases, worked into the detail of the activities. The models also differ in focus Hackos includes an extensive focus on print production, while our process concentrates on digital production and leaves print production to the style guides and design manuals, where it’s extensively covered. There are many other differences, which are too detailed and numerous to discuss here.

It’s useful to have an understanding of both processes and how they align, as they’re both popular, well-known methodologies in technical writing. In the accompanying diagram, we show how the high-level Technical Writing Process and the Hackos Information-Development Life Cycle overlap.

4. [Practice] Customize the Process

The Technical Writing Process is designed to be easily customized to suit your projects. In its comprehensive, end-to-end form, it’s a robust methodology that supports even large, complex documentation projects. Before using it, we recommend modifying it to fit your project and your organization’s unique culture, policies, and processes.

This section provides practical steps to show how this can be done successfully. We’ve also developed two case studies that showcase different implementations of the process.

4.1. Step 1: Download and Learn the Process

Start by downloading the Technical Writing Process template. It’s available on our website, https://boffin.education/, for free download: Technical Writing Process Template. Learn how it works by reading this book or taking one of our courses at https://boffin.education/technical-writing-courses/. Once you’ve built an understanding of the process, it’s time for the analysis to begin.

4.2. Step 2: Analyze Your Organization’s Requirements

Ensure you’ve developed a thorough understanding of your organization’s unique requirements. Unfortunately, you may not always have the luxury of time to do so. Perhaps you’ve been brought in as a consultant or new manager with the expectation that you’ll hit the ground running and quickly deliver results. Even so, take a few days to gather as much information as possible to build an informed understanding of the organization’s needs. Don’t just dive in! At the very least, consult some of the highly respected veterans—like senior writers—who have been with the organization for a long time and possess a wealth of accumulated wisdom.

For more guidance on information-gathering, see Chapter 9: Collect Information.

Insight

Integrating Processes: Aligning with Organizational Dynamics In addition to analyzing your organization’s requirements, it’s important to consider how your process may intersect with existing processes, such as Agile software development or product development processes. Speaking with product owners or project managers is important. These conversations can provide insights into their needs and expectations, clarifying how your process will integrate with the broader organization’s dynamics.

4.3. Step 3: Add, Amend, Delete

Now it’s time to customize the process. Begin with the macro view by considering the high-level phases in the Technical Writing Process. Some phases, such as Translate, might not be necessary for your project, so amend them as required. Then review the list of activities for each phase. Add, remove, or adjust as necessary. This stage is where you’re likely to modify the process the most. Finally, review the list of outputs to ensure they support your now-modified process.

Use the Technical Writing Process Checklist to assist you in this journey.

Tip

Balance Rigor with Flexibility in Your Process You don’t always need to define every micro step in the process. If you’re leading a team of writers, leave some room for them to exercise their craft in a way that allows them to showcase their skills while achieving your desire for consistency. This is where the writers’ adage “show, don’t tell” comes into play. Show your fellow writers how to achieve excellence with time-saving templates rather than through lengthy rulebooks.

4.4. Step 4: Iterate and Improve

You probably won’t nail the process on the first try. Processes are living frameworks—something that you will always be tinkering with and perfecting as the organization changes around you. If you’re employed by your organization on an ongoing basis, rather than as a freelancer brought in for one-off projects, you can indulge your inner perfectionist by embracing the opportunity to polish the process. Schedule regular reviews—maybe every six to twelve months—to discuss the lessons learned from everyone’s application of the process. Then feed their suggestions for improvement into the next iteration.

5. [Case Study] Case Study 1: Software Start-Up Company

Voice of Practitioner

Francis Role: Technical Writer with four years’ experience Location: United Kingdom What I Do: “I write for a fast-paced start-up that sells database software. We work in an Agile software development environment. My job is as a technical writer crafting online documentation for new features for end users.” Tools I Use: “For technical documentation, we use GitHub workflow, AsciiDoc, and Antora site generation software. We use the software development workflow process to produce documentation—that’s kind of the higher-spec industry standard for good, future-looking companies.” A Day in the Life: “Morning time is spent checking my Slack and checking emails, and then I start solving the issue I’m on. Then I get on with the writing, getting feedback from subject matter experts, and updating my documentation. I spend a lot of time learning the product and understanding the product documentation, and learning the complicated parts of the business that others shy away from. I also spend about forty-five minutes a day at lunchtime learning how to code, which my company supports with a subscription to Codecademy.” What Does My Company Value? “When you need quick turnarounds in documentation, or if you’re working with someone who doesn’t have time for you, if you’ve spent your spare time understanding the product, you become a pretty safe person in the team and very valuable in the business.”

Francis’s company, a start-up, is focused on quick releases and aligning documentation with its Agile development methodology. For this reason, Francis’s planning consists of collecting information on new features, creating a list of topics aligned with sprints, and defining his review team. He’s already familiar with his audience’s needs and the purpose of his documents, having done this work already. Now he’s relying on that knowledge to quickly move ahead with developing new topics. We’ve summarized Francis’s process below. It’s a lightweight version suitable for use in a fast-paced software development environment.

Phases	Customized Activities	Outputs
Plan	Gather Software Feature Information	Collected Information on New Features
	Make a Plan	List of Topics aligned with Sprints
	Define Review Team	Review Matrix for Topics
Design	Design Structure	Document Outline for Each Topic
Write	Agile Sprint-Based Draft Writing	Drafts of Topics
	Incorporate Visuals	Enhanced Topics with Screenshots
Edit	Edit Topics	Edited Topics
Review	Validate and Test	Validated and Accurate Topics
	Conduct Peer Review	Peer Review from Technical Documentation Team Members
	Conduct Developer Review	Developer Review Feedback
Publish	Establish Document Control	Controlled Document Versions on GitHub
	Obtain Approval	Approved Topics
	Preview Documentation	Site View on Antora
	Synchronized Software Release Documentation Publishing	Published Topics
	Communicate with Stakeholders	Slack Messages, Emails
Manage	Manage Progress	Daily Stand-Ups Sprint Reviews Jira Tickets Completed in Documentation Backlog

6. [Case Study] Case Study 2: Multinational Engineered Products Company

Voice of Practitioner

Alison Role: Manager Technical Communication Support & Processes with twenty years’ technical writing experience Location: United Kingdom What I Do: “I work for a multinational company and have a very varied role, which makes my job interesting. First, I work on customer-facing documents, so I create hardware documentation in both print and digital formats. The product line I’m responsible for includes engineered products such as servo drives and geared motors for machinery used in the food and beverage industry. I am also responsible for creating and improving all processes related to technical communication, such as the release of manuals and ordering illustrations and translations. I am the translation manager and also manage a team of four in India who support our department.” Tools I Use: “We use MadCap IXIA CCMS, both web and desktop clients. The web client has its own editor, and the desktop client uses Oxygen XML Editor. It’s a long process—we’re in the development of quite complex products here. The development from the initiation phase to market launch can take around two years.” A Day in the Life: “I generally start by looking through my emails and filtering out the easy ones. I’ll look into my to-do list and set priorities for the day. If I’ve had a draft in review with engineering, product management, and hardware, I’ll combine all the comments into a single PDF and go through it with them in a Zoom call. I’ll check for what they want to do and validate any technical feedback, e.g., whether I have the correct values for something. Some things are easier to describe with graphics, so I might be reviewing that and placing a graphics order with our illustrator. I also check if any translation requests or illustration orders have been logged and distribute tasks to our support team in India. At the end of the day, I always add a comment ‘up to here,’ so I know where I’m up to.” What Does My Company Value? “Learning how to juggle several tasks at once. You’re not going to be working on one manual at a time. You might have one manual in review, be writing another one, and finishing a review task on another. Being able to juggle and organize tasks is key.”

Alison’s company is a large multinational engineered products company. Operating for almost a century now, it has multiple product lines across infrastructure, food supply, energy efficiency, and climate-friendly solutions. It still creates printed and shipped “in-box” documentation with its products—although it’s moving away from this approach to one that focuses on creating content for multiple platforms, such as print, online, and chatbot. Alison’s process focuses on creating technically accurate content supported by schematic diagrams, all published in multiple languages on multiple platforms. Even though her company is gradually moving away from printed manuals, they’re still essential, so her process involves a heavy production component.

Phases	Customized Activities	Outputs
Plan	Collect Information, Data, and Knowledge	Collected Information, Data, and Knowledge
	Make a Plan	Documentation Plan
	Analyze Audience	Audience Profile
	Define Review Team	Review Matrix in Documentation Plan
	Estimate Scope, Time, and Cost	Skeleton File (Table of Contents)
	Develop Schedule	Project Schedule
Design	Design Structure	Skeleton File (Table of Contents)
Write	Write Drafts (First, Interim, Final)	First Draft Ready for Review Updated Table of Contents
	Include Images	Updated Document
Edit	Edit Draft	Edited Drafts
Review	Validate and Test Information	Validated and Tested Information
	Conduct Peer Review	Request for Review Review Feedback
	Conduct Subject Matter Expert Reviews	Request for Review Review Feedback
Translate	Approve Master Document/Content	Approved Master Document
	Define Target Languages	Target Languages
	Define Scope of Translation	Translation Scope
	Obtain Quotation	Translation Provider Quotation
	Translate Source Text	Draft Translated Text
	Edit and Proofread Translated Text	Proofed Translated Text
	Validate Translated Content	Validated Translated Text
	Layout Work (DTP—Desktop Publishing)	Formatted Final Draft
	Conduct Final Review	Review Feedback
	Deliver Final Format	Final Draft Content on Translation Agency Site
	Download Final Content and Import into Component Content Management System	Final Draft Ready for Publication
Publish	Establish Document Control	Controlled Document
	Obtain Approval	Approved Document
	Conduct Final Checks	Final Draft Ready for Publication
	Publish Final Version	Published Document
	Communicate with Stakeholders	Email to Stakeholders
Manage	Manage Progress	Status Tracker Updated Project Schedule

7. [Template] Technical Writing Process Template

Technical Writing Process Template

8. [Template] Technical Writing Process Checklist

Technical Writing Process Checklist

1. Hackos, J. T. (2007). Information Development: Managing Your Documentation Projects, Portfolio, and People. John Wiley & Sons., at pp. 318-325. ↩︎