Lead Writer: Kieran Morgan | Peer Reviewer/s: John New | Expert Reviewer/s: Dina Bennett, Patrick Lambe | Managing Editor: Kieran Morgan

In this chapter, you’ll explore the art of organizing technical documents to make them more user-friendly and effective. You’ll learn the importance of structure, the factors that differentiate it from information architecture, and the common taxonomies—lists, tree structures, process flows, system maps, and matrices—used in technical writing. Real-world examples and steps guide you through the process of building and iterating your document’s structure to ensure it aligns with your audience’s needs.

Who Should Read This
• Aspiring Technical Writers • Beginner Technical Writers • Career Advancers • Cross-Domain Professionals
Table of Contents: Technical Writing Process
Previous: Chapter 12: Define Review Team	Next: Chapter 14: Design Stylesheet

1. Introduction

“Taking the clay of what the developers are working with and building it into bricks is the most important part of the job.”—Colin, Senior Technical Writer

Technical writers love to build structure. There’s nothing more satisfying than taking a bunch of scattered facts and synthesizing them into a well-organized technical document. Many of the technical writers we interviewed for this book reported that this was one of the main joys of their working lives. It’s like fitting a puzzle piece into place and suddenly seeing the bigger picture come into view.

It’s not just satisfying for us, the writers; it also makes our documents more effective for our audience. When we organize information effectively, we make it easier for our users to locate the information they need quickly. This helps them achieve their goals faster—whether it’s building knowledge about how to use something or obtaining the information they need to make a decision.

When we think  about structure, the thing that comes to mind most immediately is the hierarchy of headings that forms a document’s outline, otherwise known as a table of contents. But structure goes far deeper than that. We’re going to introduce you to several concepts in this chapter, followed by steps to apply them in practice.

The first is what we call the “content sandwich”—it’s an old-fashioned but still useful means of understanding the structure of long-form documents, such as books, reports, plans, and printed documents. This method is still commonly used in publishing today.

The second is an introduction to what we call the Five Taxonomies: the most common types of structures used in technical documents. These are lists, tree structures, process flows, system maps, and matrices. You’ve probably used these already but maybe without realizing they had specific terminology.

The third is the distinction between sequential and nonsequential taxonomies. This is the difference between instructions that must be followed in a particular order versus content that doesn’t require a particular sequence to grasp it.

Understanding how to apply the right taxonomy will help you create a user-friendly document that best supports your audience’s journey.

1.1. Structure vs. Information Architecture

In your technical writing career, you’ll probably hear the words structure and information architecture used interchangeably. There’s a lot of overlap between these concepts and no single, agreed-upon definition—so if you’re a bit confused, you’re not alone.

Here’s how we differentiate them in this book:

• Structure refers to the organization within a technical document, such as a table of contents, list of procedures, or flowchart.
• Information architecture is a holistic system of information design that encompasses both the internal structure of a document and the labeling, navigation, and search subsystems beyond the document.¹

While we would love to explore information architecture, it’s beyond the scope of this book.

2. [Theory] The “Content Sandwich”: Front Matter, Text, and Back Matter

Once upon a time, the design and structure of documents were guided by well-understood conventions that had been in place for decades, if not centuries. Content is traditionally divided into several components: front matter, text, and back matter. Think of this structure like a content sandwich, with the front and back matter serving as the bread and the text as the tasty filling.

Here’s a breakdown of these elements:

• Front Matter: Typically contains the title page, version history, copyright statement, and navigational aids such as the table of contents.
• Text: Comprises the “nutritional value”—the valuable information about the topics and tasks that the user wants to accomplish or learn about.
• Back Matter: Includes all other content not essential to the topic, such as appendices and glossaries. Often incorporates additional navigational aids like indexes and tables of figures.

Finally, there’s an outer layer, or “wrapper”:

• Cover: This is where the entire content sandwich is wrapped up, as if in a metaphorical paper bag. The cover serves as the final layer, providing a visually attractive design to distinguish it from other books and to protect the hard copy from damage.

If you consult your nearest style guide, you’ll invariably find a section offering detailed guidance on laying out traditional publishing deliverables, such as books and journals. While this information is valuable, it’s primarily targeted at the publishing industry. So is it really relevant to you? Yes! Understanding these conventional structures can assist you in organizing your technical documents more effectively. It allows you to compartmentalize the components of your document, enabling more manageable planning, especially if you’re designing something lengthy—such as a report, plan, or any document that will be printed and bound as a hard copy.

What Does That Mean?

Front Matter, Text, and Back Matter In publishing, content—such as a book—is traditionally divided into several sections: front matter, text, back matter, and a cover.2 This concept is not just academic—it also applies to many other long-form or hard-copy (i.e., printed and bound) documents, such as reports, plans, and user guides.

3. [Theory] The Five Taxonomies

Let’s say you’re at the grocery store standing next to a shelf full of oranges. On the next shelf, you find lemons. Where are you? You’re in the fruit section, of course. What’s nearby? Most likely the vegetable section.

How did you know that without even thinking about it? Because it’s a taxonomy—a powerful tool that helps us make sense of the world by organizing knowledge in our minds and aiding us in decision-making.³ The taxonomy at your grocery store allows you to navigate it intuitively, as the store designers have purposely co-located vegetables and fruit to mimic the way we’ve learned since childhood to mentally classify food.

As a technical writer, you create taxonomies all the time. A table of contents in a user guide, a sequence of ordered steps in a simple procedure, a document describing a business process flow, a matrix showing software version and compatibility—all of these things are taxonomies.

Good taxonomies make technical information predictable and easy to navigate by mimicking the process that occurs inside the human brain. If you understand the common types of taxonomy, you can structure your information in predictable ways that will seem familiar to your audience, just like a shopper in a grocery store.

The five most common taxonomies in technical documentation are lists, tree structures, process flows, system maps, and matrices:

3.1. Lists

A list is the simplest taxonomy. A list is a collection of items grouped by a common purpose or function, without a hierarchical structure. Lists are the building blocks of taxonomies.

• When to Use: Ideal for straightforward information that doesn’t require branching or complex relationships. Useful in checklists, step-by-step instructions, or itemized data.

Example 1 A list of system requirements necessary to run software: • Windows 10 or later • 8GB RAM • 100GB free disk space Example 2 A guide to installing software, where each step is listed in a sequence to be followed by the user: 1. Download the installer. 2. Run installer.exe. 3. Follow the on-screen prompts. 4. Complete the installation.

3.2. Tree Structures

Tree structures are what we often think of when considering taxonomies. They are called “tree” structures because they start at a “trunk” and then branch out into multiple “branches.”

We subconsciously use tree structures all the time to make sense of our world; a classic example is a family tree. This makes them powerful tools for expressing relationships in our documentation—we all intuitively understand them, so there’s no need to explain the concept of a tree structure to anyone.

You can use tree structures to represent numerous relationships, such as parent-to-child, container-to-contained, and cause-and-effect. Tree structures can also express horizontal relationships, such as siblings along one branch. This is akin to the co-location of fruits and vegetables in a grocery store, where items of similar nature are grouped together.

• When to Use: Best for organizing information in a branching format, where main topics are broken down into subtopics, like chapters in a book.

Examples A table of contents in a user guide, showing main topics (parents) and subtopics (children): 1   About This Document 1.1   Overview 1.2   Revision History 2   Getting Started 2.1   In This Section 2.2   Log in

3.3. Process Flows

Process flow diagrams are commonly found—and highly useful—tools in the workforce. Most experienced technical writers have documented or created process flows at some point in their career, and there’s even a type of technical writer that specializes in this work—see Chapter 2: Roles Responsibilities > 2. Types Of Technical Writers.

Process flows visually illustrate the steps, decisions, and interactions involved in a process. Process flows can usually be easily identified as they show direction in workflow, typically from an input to an output, along with the actions and decisions in between. This distinguishes them from system maps (below), which show relationships between components.

• When to Use: Effective for illustrating step-by-step processes, workflows, or procedures where a sequential flow is essential.

Examples 1. User Onboarding Process: A step-by-step guide to show what a new user needs to do to successfully set up an account and start using software. • Sign-up → Email Verification → Profile Setup → Tutorial → Full Access 2. Software Deployment Workflow: A diagram that shows the flow from code commit, to testing, to deployment in a production environment. • Commit → Automated Testing → Manual Review → Deployment

What Does That Mean?

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.

3.4. System Maps

System maps are visual representations of things that interact to create an integrated whole, or a system. These can be real-world or more conceptual in nature. They use a combination of text and visual symbolism to express relationships between items in their taxonomy. System maps are excellent tools for visualizing how the parts of complex systems interact with one another, making them a great choice for technical documentation.

• When to Use: Ideal for representing complex systems (physical or conceptual) with multiple interconnected components, where the interaction between components is key.

System Maps vs. Component Diagrams

In technical documentation, both system maps and annotated component diagrams are used to explain parts of a system. However, they have some key differences. While annotated diagrams label components, offering a static snapshot, a system map goes a step further to illustrate relationships, interactions, or flows between these components.

Examples System Maps 1. Jet Engine Schematic: Schematic of a jet engine illustrating fluid dynamics. 2. Network Architecture Map: A diagram that visualizes how servers, routers, and firewalls are interconnected within an organization’s network, including data flow directions. Component Diagrams 1. Laptop Hardware Overview: A diagram that labels the main components of a laptop, such as the CPU, RAM, and ports, without detailing their interactions.

What Does That Mean?

System An integrated whole consisting of interacting components. These components can be both tangible and intangible, such as the people, processes, knowledge, equipment, and software within a company.

3.5. Matrices

A matrix is a two- (or more) dimensional table that allows for the cross-referencing of items along rows and columns. In technical documentation, matrices are particularly useful for correlating data, considering different combinations of attributes, representing complex relationships, and aiding in decision-making.

• When to Use: Useful for comparing multiple variables or showing relationships between different sets of data, like in risk assessment matrices or skill matrices.

Example: Software Compatibility Matrix

	Windows 10	Windows 11	macOS
Version A	Compatible	Not Compatible	Compatible
Version B	Not Compatible	Compatible	Not Compatible

More complex matrices, such as three-dimensional data cubes, may have multiple dimensions, but the ones you’ll typically find in documentation only have two dimensions. Matrices like this one make it easy to determine the compatibility between software versions and operating systems. This taxonomy type adds an additional layer of information that makes your documentation even more user-friendly.

4. [Theory] Sequential and Nonsequential Taxonomies

So now you know the content sandwich and taxonomies. Let’s explore another key concept in technical writing: sequential and nonsequential taxonomies. This distinction determines whether a document’s content is arranged in a sequential order or not. Understanding when to use these structures will enable you to select the most appropriate taxonomy for your audience.

• Sequential structures resemble a series of instructions, like a recipe, where each step builds upon the previous one and must be followed in a precise order to achieve the desired outcome.
• Nonsequential structures are like the layout of an encyclopaedia: individual pieces of information stand alone and can be accessed in any order.

Knowing when to apply each structure is an essential skill for technical writers. The following scenarios illustrate the practical use of sequential and nonsequential structures:

Structure	When to Use	Examples
Sequential	When accuracy depends on the completion of steps in a specific sequence.	• Procedures and process-based documentation. • Step-by-step how-to guides. • Task-oriented sections in user manuals.
Nonsequential	Where task execution does not depend on a particular order. When organizing information by themes or features rather than a process.	• Knowledge base articles. • Frequently asked questions (FAQs). • Feature descriptions in user guides. • Glossaries. • Product specifications.

As a further example, let’s consider the sections in our Sample User Guide:

• Introduction: Semi-sequential; this section provides an overview and can be read in any order, placing the most important information first.
• Getting Started: Sequential; this section guides the user through a set process.
• Features and Functions: Nonsequential; it describes product features independently of each other.
• How-To Guides: Sequential; these guides contain step-by-step procedures for common tasks.
• Troubleshooting: Nonsequential ordering of topics, with sequential ordering of steps within each topic.

This example demonstrates how the appropriate choice of sequential and nonsequential structures can create a user-friendly document. Each section’s structure is selected to best support the user’s journey through the information.

5. [Practice] Design Structure

The journey to a well-organized structure begins with your understanding of your audience’s needs, your subject matter, the type of documentation you’ll be crafting, and how it will be delivered to end users. When you’re building your structure, you’ll be using the foundation of understanding you developed in Part 4: Plan, particularly the audience analysis in your Documentation Plan.

Here’s how you do it:

1. Understand Your Audience: Start by developing as deep an understanding as you can of your audience, the tasks they need to accomplish, and their information journey by following the steps in Chapter 11: Analyze Audience.
2. Understand Your Subject: Dive deep into your subject matter. Get as much hands-on experience as you can by following the steps in Chapter 9: Collect Information. There’s no point documenting something you barely understand.
3. Interview Subject Matter Experts: Consult with subject matter experts to grasp the full scope of your documentation. Ask about key use cases, features, or modules. It might be necessary to conduct multiple interviews to draft a realistic structure or table of contents.
4. Consult Stakeholders: Discuss with stakeholders like your project sponsor or manager to understand their expectations. This is vital to refine your approach before finalizing anything.
5. Use Your Intuition: Once you’ve completed your planning and information gathering, a structure will likely begin to form intuitively. It may differ from your initial concept, but that’s perfectly normal. Use this intuitive structure as a working draft to guide your further development.

6. [Practice] Review and Iterate Structure

Even the most meticulously thought-out structure will benefit from review. As with the writing and review process, this is an iterative step, meaning you might have to go back and forth multiple times. That’s perfectly normal. By reviewing and iterating your document’s structure before you commit to writing, you’ll save yourself from having to rework your document later on and to bring your stakeholders along on the journey.

Here’s our suggested process for finessing your document’s structure:

1. Expert Review: Send your initial table of contents or structure draft to subject matter experts and stakeholders.
2. Gather Feedback: Solicit feedback from your team and others, such as potential users. Ensure you’ve covered all the important topics and addressed the questions they might have.
3. Revise: Make changes based on the feedback you’ve received.
4. Final Review: Once you’re satisfied with your structure, it’s time to start writing.

By developing an understanding of the different types of document structure and following the steps above, you can ensure you’re creating a well-organized document that’s better suited for your audience’s needs. When you feel like your draft structure is sufficiently well-developed, it’s time to start writing.

7. [Case Study] Cochlear Nucleus 6 Sound Processor User Guide

A great example of structure in action can be found in Cochlear’s range of sound processors for hearing-impaired people. While developing the processor documentation for the Cochlear™ Nucleus® 6 Sound Processors, the technical documentation team used a combination of tree structures, component diagrams, and lists of procedures to create highly visual documentation suitable for its end users.

Kieran Morgan, who was Project Manager for the Cochlear™ Nucleus® 6 documentation, explains: “We put a lot of effort into the planning stage to really understand our audience’s needs. By working with audiologists, engineers, and product managers, we realized our documentation had to cater to a wide range of demographics, including older adults and children worldwide with varying levels of literacy. So we developed a tree structure table of contents based on simple, sequential customer use cases like ‘power,’ ‘turn on,’ ‘wear,’ and ‘care.’ We color-coded these use cases and assigned them unique visual symbols to reinforce the taxonomy throughout the document, making it easier for even low-literacy customers to navigate the printed booklets and find the information they were looking for.”

8. [Sample] Sample User Guide

The Sample User Guide showcases technical writing structuring techniques and stylesheet application. Designed around a fictional scenario, this guide demonstrates clear organization and presentation of technical content, making it an ideal tool for mastering Microsoft Word’s features for document design.

1. Rosenfeld, L., Morville, P., & Arango, J. (2015). Information Architecture: For the Web and Beyond (Kindle ed.). O’Reilly Media, pp. 23-24. ↩︎
2. The Chicago Manual of Style, 17th ed. Chicago: University of Chicago Press, 2017. https://doi.org/10.7208/cmos17, s. 1.3 Divisions and parts of a book—overview. ↩︎
3. Lambe, P. (2007). Organising Knowledge: Taxonomies, Knowledge and Organisational Effectiveness. Chandos Publishing, pp. xv-xvi. ↩︎