Information Mapping

From TechWriter Wiki

Jump to: navigation, search



Information Mapping is a documentation methodology, developed by Robert E. Horn in 1972. Documents developed according to the Information Mapping methodology have an instantly-recognizable visual style. This is probably because most authors (or organizations) adopting the methodology focus on the style of the Information Mapping documentation itself, copying the style used by Information Mapping Inc. for their own documentation on Information Mapping. However, Information Mapping really stipulates the structure of the information, rather than the visual display of it. It is perfectly possible to adhere to the methodology but use a visual style that is markedly different to what is commonly thought of as 'Information Mapping documentation'.

Information Mapping is built on seven key principles. These are:

  1. Chunking;
  2. Relevance;
  3. Labeling;
  4. Consistency;
  5. Integrated graphics;
  6. Accessible detail;
  7. Hierarchy of chunking and labeling.


The methodology states that:

"Writers should group information into small, manageable units."

Information Mapping defines a 'manageable unit' as "no more than nine pieces of information", which is based on the oft-quoted 'seven-plus-or-minus-two' rule. Information Mapping dictates that this should apply to all levels of documentation - so a manual should have no more than nine chapters, and a bulleted list should have no more than nine list items. However, as discussed in Writing user instructions, this is not always practicable or necessarily desirable. That said, this principle - that information should be grouped into small, manageable units - is good advice from a comprehension perspective.


The methodology states that:

"Writers should make sure that all information in one chunk relates to one main point based on that information's purpose or function for the reader."

Put simply, this rule states that a block of information should contain only one type of information. This means that you should not mix (for example) instructions with descriptions. Obviously both of these types of information are permissible (and often necessary) within the same publication. Information Mapping just states that they should be in separate 'blocks' within the document. So you may have a section called "How the XYZ works" and another called "Replacing the widget on the XYZ".


The methodology states that:

"After organizing related sentences into manageable unit, writers should provide a label for each unit of information."

This rule states that each 'chunk' of information should have a 'label'. Many proponents of Information Mapping think that this label should appear (traditionally) on the left of the block of information, and word-wrapped within the label column. However, this is not strictly necessary. It is perfectly valid for the label to appear as a 'normal' heading that stretches into the 'content' column. In this context, 'labeling' is best interpreted as providing adequate headings, although headings will typically appear much more often in documents developed according to the Information Mapping methodology than in 'regular' documents.


1. 'Traditional' Information Mapping block:

Company policy for system Userids

All users are required to keep their password secret. Users must change their password the first time they log onto the system, and then once a month thereafter. If a user does not change their password for 35 days, they will be prompted to do so by the sytem when they attempt to log on.

2. Adapted Information Mapping block:

Company policy for system Userids
  All users are required to keep their password secret. Users must change their password the first time they log onto the system, and then once a month thereafter. If a user does not change their password for 35 days, they will be prompted to do so by the sytem when they attempt to log on.

The important thing to remember is that labels must stand out from the text, to allow quick scanning (navigation via the labels). For this reason, it is recommended that the 'content' is always significantly indented (as shown in Example 2 above).


The methodology states that:

"For similar subject matters, writers should use similar words, labels, formats, organizations, and sequences."

Consistency should be adhered to on two levels:

  • Consistency in language;
  • Consistency in format and structure.

Consistency in the language used within a document and across multiple documents within the same documentation set is important, as readers will rapidly become accustomed to the language used and will not have to 'decipher' the text. That is, they will not have to think about the meaning of a word, but will know intuitively (based on their earlier intraction wih this word) what is meant. If you use different words or phrases for the same thing, the user will be required (perhaps subconsciously) to decide each time whether this actually is the same thing as was referred to previously, or is something different. This will increase the time it takes them to assimilate the information.

Consistency in the format and structure of a document is also important. Within a single document, headings should be used consistently. This includes using the same size and typeface for headings at the same level, and also using headings at the same level of granularity. Across documents, consistency can be thought of as providing the same information in the same type of document. For example, if you are developing a suite of user procedures, then every user procedure document should contain the same information, at the same point in the document, and using the same headings and labels.

Integrated graphics

The methodology states that:

"Writers should use diagrams, tables, puictures, etc. as an integral part of the text, not as an afterthought added on when the writing is complete."

This simply means that graphics should be included wherever they are useful. This rule was probably included as a reaction to the prepondency for text-only documents. Integrating graphics typically gives a document a 'lighter' (less-dense) feel, and therefore facilitates comprehension. There are also times when a picture can show instantly what it would take several paragraphs of text to explain.

However, graphics in technical communications must always be functional. The Information Mapping documentation states that "approximately 50 percent of the adult population learns better from pictures and other graphics than from words", but this means that approximately 50% learn better from text! Therefore, graphics should always be in support of the text, and not as an alternative to it.

Note that Information Mapping considers tables to be 'graphics' as well - which explains their extensive use in Information Mapping. However, given that most tables contain text only, it is better to exclude tables from the definition. This allows you to better focus on 'real' graphics (including photos, technical illustrations, and charts and graphs) and identify opportunities for including these in a document.

Accessible detail

The methodology states that:

"Writers should write at a level of detail that makes the information the reader needs readily accessible, and makes the document usable for all readers. In other words, put what the reader needs where the reader needs it. Include clearly labeled overviews, reviews, descriptions, diagrams, and examples for all "abstract" presentations. Place the diagrams, and examples close to the text they illustrate."

This principle can best be interpreted as simply providing information to a level of detail that is useful to the readers, and then making sure that the readers can easily-locate the relevant detail.

For example, in a set of maintenance instructions, saying simply "Remove the spigot shaft" may not be sufficient. Perhaps the reader does not know how to do this. Consider providing instructions explaining exactly how to remove it. Perhaps the reader is even unfamiliar with exactly what a spigot shaft is, and where it is located. So provide a diagram of one, and/or a photograph of a spigot shaft in-situ. Then clearly label each element - the instructions, the diagram and the photograph - so that users can directly locate them and understand what the element is showing.

Hierarchy of chunking and labeling

The methodology states that:

"Writers should organize small, relevant units of information into a hierarchy, and provide the larger group(s) they have created with a label(s)."

At its simplest, this rule simply means that:

  1. A document should have a title (label in Information Mapping terminology);
  2. The document should be split into sections (maps);
  3. Each section should have a title (label);
  4. Each section should be split into units of information (blocks);
  5. Each unit of information should have a title (label).

Some authors struggle with Information Mapping, thinking that there are only three levels within this hierarchy: document, map, and block. This assumption is largely borne out of using the Information Mapping documents as an example, and using the Information Mapping templates which indeed only include these three levels.

However, if you consider this rule in conjunction with the 'chunking' rule, it effectively supports as many levels of the hierarchy as is necessary - as long as each node in the hierarchy has no more than nine sub-nodes.

It is also often assumed that heading numbers are 'no allowed', but again, this is a fallacy. In a three-level hierarchy, where the document is the highest level, and there are no more than 9 nodes at each level, there is not really a need for section numbers. However, once additional levels are inroduced, or the number of nodes is increased, heading numbers - and specifically hierarchical heading numbers (1, 1.1, 1.2, 1.3, 2, 2.1....) can greatly aid navigation. Information Mapping does not explicitly forbid them, so they can be used where it helps.


Corporate Security Policy

1. Controls on system access

1.1 System userids

Each user will be granted a unique password-protected userid which will allow them access to all (and only) functions required to perform their job. Userids must not be shared with other users, under any circumstances.
1.2 System passwords All users are required to keep their password secret. Users must change their password the first time they log onto the system, and then once a month thereafter. If a user does not change their password for 35 days, they will be prompted to do so by the system when they attempt to log on.
2. Controls on physical access to buildings

2.1 Card key


Personal tools