designing-document-structure-and-presentation

name	designing-document-structure-and-presentation
description	Treat layout, typography, white space, structure, graphics/screenshots, the table of contents and space constraints as communicative usability factors, and build modular, navigable, task-centred guides.
kind	skill
status	ready
provenance	{"principles":["P004","P005","P012","P016","P028","P029","P038","P047","P083","P106","P124","P147","P148"],"claims":["C00005","C00136","C00155","C00164","C00181","C00188","C00195","C00202","C00211","C00259","C00266","C00330"],"evidence":["E00004","E00122","E00141","E00149","E00164","E00171","E00178","E00185"],"source_anchors":[]}

Designing Document Structure and Presentation

Purpose

This skill guides the translator to treat layout, typography, white space, structure, graphics/screenshots, the table of contents and space constraints as communicative usability factors, and build modular, navigable, task-centred guides. It advises on the decision; it does not produce the final translation, override the client's brief, or sign off safety-critical or legally-mandated content — those are handed back to the translator and the commissioner.

When to use

• Laying out printed or visual instructional information.
• Readers must navigate, read, and trust printed or formatted documentation.
• Users rely on the guide to learn or complete software tasks.
• Users need to navigate, learn, and reuse guide sections independently.
• The target text must function as professional technical documentation.
• A guide serves beginners, regular users, and advanced users across multiple use scenarios.
• A guide serves learning, task execution, scanning, searching, and reference use.
• A guide uses illustrations, screenshots, or interface references.
• Organizing a guide or restructuring a translation.

Procedure

1. Design visual presentation around human perception: balance contrast, limit color codes, avoid all-cap running text, and use Gestalt grouping deliberately. (P004)
2. Treat appearance, layout, typography, white space, and format as communicative usability factors, not decoration. (P005)
3. Make user guides task-centered teaching interfaces rather than repositories of system information. (P012)
4. Build modular, navigable guides with small functional task units, meaningful headings, useful overviews, and reader progress points. (P016)
5. Match target-language technical conventions and required document form while preserving correctness and usability. (P028)
6. Design user guides to support starting, productivity, troubleshooting, and experience-level differences. (P029)
7. Support both reading-to-learn and reading-to-do, including sequential reading and random lookup. (P038)
8. Use graphics deliberately and control translated screenshots against the final localized interface. (P047)
9. Choose user-guide structure from product nature, audience background, and user tasks while avoiding information overload. (P083)
10. Choose delivery medium according to how users actually read and use the documentation. (P106)
11. Where a document contains screenshots, treat it as bound to the external software interface: accurately reproduce the text shown in the interface, phrase all references to the software consistently, and update the document whenever the software changes, since a picture of the screen is far more effective than verbal description. (P124)
12. Do not translate an auto-generated table of contents first or in place: it is a projection of the actual heading text, so a translation typed into it is lost when the document is printed or updated — translate the real headings instead — and leave the table of contents until last, after the sections it describes, to avoid mistranslating headings out of context. (P147)
13. Meet strict space constraints (single-sheet leaflets, software string limits, diagram labels), knowing a translation naturally expands or contracts by language combination and direction, by using short simple words and sentences, clear abbreviations (preferably company or subject ones, without overuse), deviation from the source structure where a shorter target grammar allows, imperative verb forms, and flexible use of modulation, transposition, and adaptation. (P148)
14. Emit recommendations highest-impact first, in the format under Output, flagging where a draft or plan departs from the principles above.

Inputs

• The document or excerpt under translation (or its type) and the target-text function.
• The audience, their tasks and prior knowledge, and how the text is used and distributed.
• The translation brief, any client style guide, mandated terminology, and the constraints in force (deadline, format, space, safety/legal status).

Output

Per recommendation: name the applicable principle(s), tie the advice to the audience, brief and target-text function, state the trade-off or residual uncertainty, and end with a concrete next step. Order recommendations highest-impact first. The advisor never delivers the translation or makes the client's commercial or final linguistic decision — that is handed back to the translator and the commissioner.

References

See ../../references/technical-translation-principles-index.md for the full principle catalogue and ../../references/technical-translation-evidence-notes.md for grounding notes. For adjacent concerns, see the sibling skills: analyzing-audience-brief-and-skopos, selecting-translation-strategy-and-procedures, grounding-translation-in-reader-cognition, handling-terminology-units-and-nomenclature, applying-iconic-linkage-and-consistency, matching-document-type-and-genre, planning-usability-evaluations, running-and-analyzing-usability-studies, assuring-quality-safety-and-practice.

Provenance

Derived from P004, P005, P012, P016, P028, P029, P038, P047, P083, P106, P124, P147, P148, grounded in Jody Byrne's Technical Translation: Usability Strategies for Translating Technical Documentation (2006) and Scientific and Technical Translation Explained (2012) (distillation-only). The frontmatter provenance block lists the exact principle, claim, and evidence ids, which resolve into principles/principles.yaml, analysis/claims.jsonl, and evidence/evidence-records.yaml.