Word Manual Writing Basics - Bad Examples and How to Fix Them
· Go Komura · Word, Manual Writing, Documentation Design, Business Improvement
Operation manuals, work instructions, maintenance procedures, internal runbooks. What pays off later in documents like these is not writing skill itself, but whether you are using Word as “a tool for tidying up appearances only.”
Approaches that look fast at first —
- building headings out of nothing but bold and font size,
- hammering spaces and Tab to line things up,
- pressing Enter repeatedly to reach the next page,
- typing the table of contents and page references by hand,
- mixing revision requests into the body as red text —
once these creep in, the document breaks with every revision.
In this article, we lay out the Word basics that genuinely matter for manual writing, in the form of bad patterns paired with best practices.
The assumed setup is desktop Word as the main tool, with .docx as the primary format.
Table of Contents
- The conclusion first
- Do not turn Word into a tool for manual alignment
- Bad patterns and best practices at a glance
- Points that matter in practice
- The bare minimum for a manual-writing Word template
- Pre-distribution checks
- Summary
1. The Conclusion First
Here are the conclusions up front. What pays off in manual writing are these four points.
-
Let Word’s features own the structure Headings, numbering, the table of contents, references, and page control are managed via Word’s styles, fields, and breaks — not typed by hand.
-
Do not let whitespace own the alignment Spaces, repeated Tabs, and stacked blank lines break every time you make a fix. Use paragraph settings, indents, tables, and sections.
-
Do not mix review into the body Revision instructions go into comments and tracked changes, not red body text. It becomes clear what was finalized in the final version.
-
Update the automatic elements right before distribution Update the table of contents, page numbers, cross-references, and figure/table numbers all at once at the end. Check accessibility before producing the PDF.
2. Do Not Turn Word into a Tool for Manual Alignment
The most important thing in manual writing is separating appearance from structure.
For example, these are inherently “structure”:
- Chapters, sections, subheadings
- Step 1, Step 2, Step 3
- Figure 2-1, Table 3-2
- “See Chapter 4”
- No page number on the title page only
- The revision history at each update
But in fragile documents, all of this structure gets handled as “appearance tweaks”:
- Enlarging text to make it look like a heading
- Typing
1.by hand - Aligning with spaces
- Pushing to the next page with Enter
- Typing “see page 3” as literal text
With this approach, fixing one spot breaks something somewhere else.
Word ships from the start with features for holding a document as structure: heading styles, tables of contents, paragraph settings, multilevel lists, headers/footers, section breaks, captions, tracked changes, the Accessibility Checker, and more. For manuals, just using these basics eliminates a great many accidents.
3. Bad Patterns and Best Practices at a Glance
| Item | Bad pattern | Best practice |
|---|---|---|
| Headings | Build the chapter structure with bold + font size only | Use Heading 1 / Heading 2 / Heading 3 |
| Alignment | Line things up with spaces and repeated Tabs | Use paragraph settings, indents, tab stops, tables |
| Page control | Push to the next page with repeated Enter | Use page breaks and section breaks |
| Table of contents | Type the TOC by hand | Heading styles + automatic TOC |
| Step numbering | Type 1. 2. 3. by hand |
Use numbered lists / multilevel lists |
| Headers and footers | Enter them directly on each page | Use headers / footers and page numbers |
| Figures and tables | Paste images with no title | Add captions, body explanation, and alt text |
| Revisions | Leave red text and color coding in place | Review with tracked changes and comments |
| References | Write “see page 3” or “the figure above” by hand | Use cross-references and field updates |
| Formatting rules | Appearance differs by author | Decide the template and styles first |
4. Points That Matter in Practice
4.1 Building headings out of bold and font size only
Bad pattern Enlarging the text, making it bold, and settling for something that merely “looks like a heading.”
Why it hurts Word does not treat that line as a real heading. Navigation via the Navigation Pane becomes harder, and the line does not appear in the automatic TOC. From an accessibility standpoint too, appearance-only headings are a disadvantage.
Best practice
Assign Heading 1 / Heading 2 / Heading 3 to chapters, sections, and subheadings.
When you want to change the look, edit the style — not the bold or font size of each line.
4.2 Aligning with spaces and repeated Tabs
Bad pattern Filling the gap between an operation name and its description with spaces, pushing the version number to the right edge with repeated Tabs, inserting stacks of blank lines instead of paragraph spacing.
Why it hurts One extra character and it all breaks. Font changes, added paragraphs, PDF conversion, and co-authoring all knock things out of line.
Best practice Let paragraph settings, not characters, own position and spacing. Use indents, tab stops, spacing before/after paragraphs, and tables where needed.
4.3 Page breaks via repeated Enter
Bad pattern Wanting the next chapter to start on a new page, so pressing Enter over and over.
Why it hurts The moment one line is added on an earlier page, everything shifts. Blank pages creep in, a title gets stranded on the previous page, and headers or footers switch at unintended places.
Best practice
Use a page break at the start of each chapter, and a section break wherever the handling of page numbers or headers/footers needs to change.
When things break, turn on the ¶ display and inspect the page breaks and paragraph marks while they are visible.
4.4 Do not hand-type the TOC, numbering, or cross-references
Bad pattern
Building the TOC page by hand and retyping chapter names and page numbers every time.
Typing 1. 2. 3. or 1.1 1.2 directly into the body.
Writing “see page 12” or “see Figure 3” as literal text.
Why it hurts Every revision produces missed updates. The classic accident: the page number gets fixed while the heading name stays stale.
Best practice Build an automatic TOC from the heading styles. Hold steps as numbered lists and the chapter/section hierarchy as a multilevel list. Hold references to figure numbers, page numbers, and chapter numbers as cross-references and fields, and update them all at once at the end.
4.5 Do not type headers/footers and version numbers directly on each page
Bad pattern Entering the document name, version, and page number directly onto every page. Hand-tuning the layout because the title page is supposed to be different.
Why it hurts You forget to update the version, the page numbers drift, and things break the moment you want only the appendix to use a different format.
Best practice
Move the document name, version, and page numbers into the header / footer.
For a distinct title page use Different First Page; to switch per chapter or appendix, use section breaks and unlink Link to Previous for the header / footer.
4.6 Separate tracked changes, comments, and figures/tables
Bad pattern Leaving notes like “fix this,” “unverified,” “needs discussion” in red text, and letting them ride into the final version. Pasting full-screen screenshots with no figure number and no explanation.
Why it hurts It becomes impossible to tell what is body text and what is a note from mid-review. It is also how review traces end up in the final version.
Best practice Put the edits themselves in tracked changes, and discussions or instructions in comments. Give figures and tables captions, and set alt text where needed.
5. The Bare Minimum for a Manual-Writing Word Template
You do not need an elaborate template right away. At first, this much is enough.
| Element | Use | Minimum rule |
|---|---|---|
| Document title | Cover / opening title | Carry the document name, version, creation date, revision date |
Heading 1 |
Chapter | Included in the automatic TOC |
Heading 2 |
Section | Included in the automatic TOC |
Heading 3 |
Subheading | Use only when needed |
Normal |
Body | Base text |
| Numbered list | Steps | Use for operating procedures |
| Bulleted list | Supplements | Use for enumerating conditions and cautions |
| Figure caption | Figure numbers | Figure 1, Figure 2… |
| Table caption | Table numbers | Table 1, Table 2… |
| Header / footer | Shared information | Document name, version, page number |
In addition, deciding the operating rules to about this level makes everything afterwards much easier.
- The master copy is
.docx - Distribution is as PDF
- Revisions use tracked changes
- Update fields before distribution
- Run the Accessibility Checker before distribution
6. Pre-Distribution Checks
Before turning the manual into a PDF, you want to check at least these.
6.1 Update all fields
Select the whole document with Ctrl + A and update the fields.
This reduces missed updates in the TOC, page numbers, cross-references, and figure/table numbers.
6.2 Clean up tracked changes and comments
Check that no mid-review changes or comments remain. Beware the case where they are “merely hidden” but still present.
6.3 Check the heading levels
Confirm the chapter structure is consistently Heading 1 / 2 / 3.
If this is inconsistent, the TOC and navigation fall apart.
6.4 Check images and tables
Confirm figures and tables are numbered, images are not oversized, and the body explains what to look at.
6.5 Run the Accessibility Checker
Run the Accessibility Checker and confirm there are no problems with headings, alt text, contrast, table structure, and so on. If PDF distribution is the plan, it is safer to get this right on the Word side first.
7. Summary
The thing you most want to avoid when building manuals in Word is holding even the structure by hand.
- Headings via styles
- Steps via the numbering features
- The TOC automatic
- Page control via page breaks and sections
- Figures and tables via captions
- Review via tracked changes and comments
- References via cross-references
- Updates and checks before distribution
In short: do not stop at using Word as “a tool for typing characters” — use it as a tool for managing document structure.
Manuals show their differences not at the moment of writing, but at the moment of fixing. A document that breaks with every revision is usually one whose Word fundamentals broke before its content did.
Put the other way around, just nailing these basics raises a document’s maintainability considerably. There is no need to aim for elaborate design at first. The practical starting point is taking these five out of manual labor: headings, numbering, the table of contents, page breaks, and review.
Related Articles
Recent articles sharing the same tags. Deepen your understanding with closely related topics.
How to Place Images, Figures, and Screenshots in Word Manuals Without Breaking the Layout
To keep images, figures, and screenshots from breaking in Word manuals, we walk through in-line placement, captions, anchors, spacing, te...
Real-Time Systems Programming in Ada — Priorities, Periodic Execution, and CPU Time Control in Practice
A practical deep dive into Ada's Annex D real-time features — task priorities, the Ceiling_Locking protocol, drift-free periodic executio...
Fable Is Gone — Don't Give Up: OpenRouter Fusion + Chinese LLMs + Review Layer
Fable is nowhere near replaceable. But combine OpenRouter Fusion with 5 Chinese LLMs, then add a review layer (GPT-5.5-Pro or Codex PR re...
Safe Concurrency with Ada — A Practical Guide to Tasks and Protected Objects
A practical introduction to Ada's built-in concurrency model — tasks, rendezvous, and protected objects. Covers the rendezvous pattern (e...
The Appeal of the Ada Language — Expressing Design Through Types and Powering Software That Runs for Decades
An introduction to the appeal of the Ada language: strong typing, range constraints, separation of specification and implementation via p...
Related Topics
These topic pages place the article in a broader service and decision context.
Windows Technical Topics
Topic hub for KomuraSoft LLC's Windows development, investigation, and legacy-asset articles.
Where This Topic Connects
This article connects naturally to the following service pages.
Technical Consulting & Design Review
This is closer to a consultation about document design, templates, and operating rules than about the fine details of Word operation itself.
Author Profile
Profile page for the article author.
Go Komura
Representative of KomuraSoft LLC
Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.
Public links