A user finds answers on how to use a product in various ways; by searching the internet, by using the traditional manual, in paper or electronic format etc. A certain user in a certain situation need answers and we, as technical communicators, carefully arrange many answers (topics) in a deliverable (map). The answers in the map are sorted and organized according to some principle. But, why do we sort and organize the topics we have referenced in the map?

Do we do it just for the fun of it? Why do we just not put our topics in a flat hierarchy without any titles? Like in a novel that does not have any headings? What purpose does the map have other than allowing us to pin point the topics that we want to include in a build project? Well the answer is obvious, or?

There are several reasons to the organizing habits. Think about it. Let us explore the most important reason, but to do so we need to take a step back.

Users are not reading a manual as a novel (some eccentric might). Users are fully occupied with making the product work properly. The minimalist approach says that users are active and they care about making the product work but not read about it. Users explore and use the product based on existing knowledge and when this knowledge insufficient and the product interface fails to communicate its use, the users looks elsewhere to find answers that help them back on track. This is true for many types of products. But for some type of technology, such as big machine products, users a less likely to explore and try, instead they plan the deployment and use carefully.

So users are searching for information at a certain point. They stick their nose into any type of documentation trying to get the answer (=one topic) as quickly as possible to get back to product use. Then one reason to organize topics in a map could be to make a topic easy to find.

But how do we help the user in making content easy to find? We put a title to every standalone topic and the titles are assembled into a table of content. We mark up keywords in the topics to build indexes. We add metadata to classify content. The topic titles, including alternative navigation titles and short descriptions, keywords and classification metadata becomes a meta textual layer above the answers that resides within the topics. Users search this meta textual layer when trying to find answers.

There is not a “one-type-of-search-strategy” among users. Some users are methodical whereas some are irrational. Users express a keyword to search for. Which keyword to express probably depend on many factors such as mental models, experience etc (see the article "Is it easy to find information in a manual?" in the winter edition of Communicator).

In electronic environments the user can enter a keyword and a search engine scans the content/meta textual layer for matches. Users can also filter (narrowing) the content to search in by selecting metadata, where occurrences that do not meet the selected metadata, are filtered out (faceted search). If a keyword search fails the user might start to scan the topic titles, assembled in a hierarchy such as a table of content or folder structure.

How do we build the meta textual layer to make it easy to find an answer? Do we mix task and descriptive content in the same deliverable or separate them into separate deliverables? How shall task topics be organized? Shall the tasks, that are done most frequently or the task topics that are needed when user must act quickly to avoid injuries, be organized on top in the map? Shall the meta textual layer reflect the way the topics are organized in the DITA map, meaning that the topics appears in the same order in the meta textual layer as in the map? A topicmap (the topicmap standard) or a subject scheme map allows us to build the meta textual layer above the content without touching the DITA map.

Well, no matter which principle I believe that the key is to make the user aware of which type of content is available and how it is organized. It probably becomes easy to find an answer if the user understands what type of content is included and how it is organized.  This is a hypothesis in an ongoing research project in Sweden.

Take the phone book as an example. We all know that a phone book contains names and numbers (let’s say that each occurrence corresponds to a DITA topic). The names are sorted in alphabetical order sorted per family name and grouped according to the alphabetical letters. I do understand this content organizing principle and I do not have problems in finding a number no matter the size of the phone book. Think about a phone book with a totally different organizing principle. The family names starting with A are sorted according to the geographical orientation in the city (north and south) and the names starting with B are sorted after age and … If you didn’t know the principle it is surely difficult to find anything. This is the reality for many user of technical documentation.

Develop a logical organizing principle and apply a consistent design pattern throughout the deliverable. Tell the user about the principle. If the principle is to complex and has too many “but if, else” it takes to much energy to understand and the user is not helped anyway.

Take DITA for example; how many users know that a deliverable made in DITA consists of task, concept and reference? Do you include information in your deliverable that says “This manual is made according to the DITA standard where some information is task oriented and some information is conceptual. The task information is always sorted as the first entries in every chapter according to… The idea behind the conceptual information is to support… “. Consider sharing any examples of such meta text; join the SeSAM group on LinkedIn and upload your example.

The ultimate situation is when technical documentation is standardized. Think about the situation where all manuals for every technical product followed the same design pattern. A user that has learnt the principle has no problems in using a manual for a different product. There are a lot of standardized genres; daily newspapers for example all follow almost the same design pattern (they include “chapters” with domestic news, international news, culture, sports, entertainment etc). Also, a car interior is to some extent standardized. The steering wheel is in front of you and the gas pedal is the right most pedal etc.

It is not only about organizing *any* content. It is equally important for techical communicators to identify what type of content end users are searching for. SeSAM (www.sesam-info.net) is an example of an information type architecture and organizing principle for technical documentation that can be used on top of the DITA principles, further refining the type of tasks and conceptual information needed.