Best Practices for Structuring Technical Texts: Headings, Numbering, and Tables

A technical document succeeds or fails on how easily a reader can find what they need. A maintenance engineer searching for a single procedure, a student revising for an exam, or an officer scanning a policy manual rarely reads from start to finish. They jump, scan, and locate. The structural elements of a document – its headings, numbering, and tables – are what make this possible. For an editor, getting these right is not cosmetic work. It is the difference between a document that communicates and one that confuses. This post breaks down how to use these three tools well, and what an editor checks before a technical text goes out.

Why structure carries the message 🔗

Readers do not consume technical material the way they read a novel. Research from the Nielsen Norman Group on reading behaviour shows that people scan text in patterns, picking up headings, highlighted words, and the first few words of paragraphs rather than reading every line. Technical structure exists to support that behaviour. When headings act as signposts and numbering acts as a map, the reader spends energy on understanding the content instead of hunting for it.

This is why the editorial process treats structure as a core review task, not an afterthought. An editor checks that the skeleton of the document is sound before worrying about polish. A logically organised text with consistent headings and reliable numbering is already half-edited.

Effective use of headings 🔗

Headings and subheadings divide a document into sections the reader can grasp at a glance. A good heading tells the reader exactly what the section contains, so they can decide whether to read on or skip ahead. The clearest technical guidance, summarised in resources like Technical Writing Essentials, recommends descriptive headings that use concrete language over vague or generic labels.

Build a clear hierarchy 🔗

Headings work in levels. A main section heading sits above its subheadings, and each subheading sits above its own detail. This hierarchy must be visually obvious – through size, weight, or spacing – so the reader instantly understands which heading is a parent and which is a child. A common editorial guideline is to aim for roughly two to four headings per page in shorter documents. Too few, and the text becomes a wall; too many, and the headings stop meaning anything. A heading should sit above at least one full paragraph; if every sentence has its own heading, the organisation needs rethinking.

Keep wording and capitalisation consistent 🔗

This is where editors do their most careful work. Headings at the same level should follow parallel structure – the same grammatical form throughout. If one main heading is a noun phrase (“Installation requirements”), the others at that level should be noun phrases too, not a mix of nouns, questions, and verb commands. The same rule applies to capitalisation. A document should pick one style – sentence case or title case – and apply it to every heading of a given level without exception. Inconsistency here is jarring and signals carelessness, even when the content is sound.

Match the heading to the content 🔗

A heading is a promise. If it says “Safety precautions,” the section must deliver safety precautions and nothing else. During editing, text often shifts – paragraphs get moved, sections get expanded – and a heading that once fit may no longer match what follows it. Re-reading each section against its heading is a standard final check, as guidance from NTNU’s writing resources notes. Accurate headings also help screen readers and assistive technology navigate the document, which matters for accessibility.

Numbering systems for hierarchy and sequence 🔗

Numbering does for sections what headings do for content: it shows the reader where they are. In a long technical manual, a numbered structure lets a reader pinpoint their exact location and lets a writer point to any part of the document precisely.

Decimal numbering 🔗

The decimal system is the workhorse of technical documentation because it shows hierarchy directly. Section 2 contains sections 2.1 and 2.2; section 2.1 may contain 2.1.1 and 2.1.2. The number itself reveals the position – a reader seeing “2.3.4” knows it is the fourth subsection within the third section of chapter 2, without reading a word. This system scales to deep structures while staying logical, which is why standards bodies and government technical manuals favour it.

Roman numerals and outline numbering 🔗

Traditional outline numbering mixes Roman numerals, capital letters, Arabic numerals, and lowercase letters (I, A, 1, a). Roman numerals also commonly mark front matter – prefaces, tables of contents – separately from the main body. This style is visually distinctive, but it becomes awkward beyond three or four levels and is harder to use for cross-referencing than plain decimals. Many non-technical readers also find dense numbering intimidating, a concern raised in technical communication discussions. The editor’s job is to weigh clarity against complexity and pick the lighter system when the content allows.

Applying numbering uniformly 🔗

Whatever system is chosen, it must be applied without slips. Editors watch for a recurring set of errors: skipped numbers (jumping from 2.3 to 2.5), duplicate numbers (two sections both labelled 3.2), mixed formats within one document, and broken subordination (a 1.1.1 appearing with no 1.1 above it). Automatic numbering features in word processors prevent many of these, but they introduce their own risks when sections are moved, so the numbering still needs a manual pass before publication.

Formatting tables and graphics 🔗

Tables and figures carry information that prose handles poorly. A table lets a reader compare values across rows and columns at a glance; a chart reveals a trend that a paragraph of numbers would bury. But a visual only works if it is labelled and placed correctly, and this is a major part of editorial review.

Labels, titles, and captions 🔗

Every table and figure needs a number and a descriptive caption. The standard convention places table captions above the table and figure captions below the figure – tables are read from the top down, so the reader wants the label first. Tables and figures are numbered in separate sequences: Table 1, Table 2, Figure 1, Figure 2, and so on. The caption should do more than name the visual; as Cornell’s engineering guidance points out, a strong caption interprets the visual so the reader grasps its point without digging through the surrounding text.

Clear labelling and proportion 🔗

Inside the visual, every element must be labelled. For a graph, that means clearly marked axes with units, as the Utah State University Engineering Writing Center advises, plus an axis that includes zero so a trend is not visually exaggerated. For a table, every row and column header must be clear. Visuals should be proportionate – large enough to read without strain, but not so large they dominate the page. Editors also check that colour is used judiciously, since some readers are colour-blind and others print in black and white; dashed and dotted lines can distinguish data series where colour cannot.

Crediting sources 🔗

If a table or figure comes from another source, the source must be stated in or below the caption. Journal guidelines such as those from AIAA require that every figure be cited in the text in numerical order and placed near its first mention. The wording of the credit signals what was done: “Source:” for a reproduced visual, “Adapted from” for one that was modified, and “Data obtained from” when only the underlying data was reused. Editors verify that these credits are accurate and that no visual sits on the page without being referred to in the body text.

Cross-referencing in long documents 🔗

Numbered sections, paragraphs, figures, and tables make cross-referencing possible – and cross-referencing is what holds a long technical document together. A specification can say “see section 4.2” or “as shown in Table 3,” and the reader can jump straight there. As an analysis of document numbering explains, the purpose of giving each component a unique number is precisely to allow distant parts of a document to refer to each other and to help readers locate those parts.

The editorial risk with cross-references is that they break. When a section is added or removed, every “see section 4.2” elsewhere in the document may now point to the wrong place. Automated cross-reference fields in modern word processors update themselves when numbering changes, which is far safer than typing references by hand. An editor’s final check includes confirming that every cross-reference still leads where it claims to – a broken reference quietly destroys a reader’s trust in the whole document.

What do you think? When you last used a technical manual or textbook, did its headings and numbering help you find what you needed, or did you have to fight the structure to get there? And if you were editing a long document, which structural check would you run first – the headings, the numbering, or the cross-references?

References

1. https://www.nngroup.com/articles/how-users-read-on-the-web/
2. https://pressbooks.bccampus.ca/technicalwriting/chapter/headings/
3. https://i.ntnu.no/en/academic-writing/headings
4. https://techcomm.nz/Story?Action=View&Story_id=213
5. https://pressbooks.bccampus.ca/technicalwriting/chapter/figurestables/
6. https://chec.engineering.cornell.edu/visuals/captions-for-figures-in-documents
7. https://engineering.usu.edu/students/ewc/writing-resources/tables-figures
8. https://aiaa.org/publications/journals/journal-author/guidelines-for-journal-figures-and-tables/
9. https://www.researchgate.net/publication/2575182_Numbering_Document_Components