31 Oct Significance of Taxonomy in Information Architecture
Significance of Taxonomy in Information Architecture
— Ashutosh Ambike
Taxonomy is the practice and science of classification.
Knowingly or unknowingly, we use taxonomy several times a day. Be it online shopping, ordering food online, booking tickets, or searching for information on the internet. We use it every time while narrowing down our expected results by using some criteria. This is nothing but taxonomy that is defined by the content owners.
Let us take an example of Online shopping.
In this article:
- Information Architecture (IA)
- Content Creation
- Publishing the Content
- Searching the Content
- Managing the Taxonomy
Taxonomy Classification
First Level
Second Level
Third Level
Good taxonomy practice i.e., better classification of products helps the customers find products easily.
Let us see how taxonomy is used by publishers for Information Architecture (IA) to create, and publish content, and end users can search and access the content seamlessly, using taxonomy.
Information Architecture (IA)
IA is the basis of the content structure. It is a map of how content is organized. A good IA can simplify the content creation process and how it is maintained, revised, and delivered. IA follows the systematic classification of the content, for example, types of manuals, end users, regulatory bodies, regions, products, types of delivery, or access levels specific to the company. All these are different ways to classify the content i.e., taxonomy.
Content Creation
Topic-based authoring is followed in a structured authoring environment. These topics are the smallest chunk of information specific to a product, application, or procedure. A well-defined taxonomy can help authors create content easily in a structured way. These small topics can be used for multiple projects, products, or procedures as applicable.
Let us take an example of how content is created for a Software Release Notes in its predefined structure. The first heading is defined as New Features added to the release. A topic is added to the heading and each topic is assigned a taxonomy. In this case a SW release number, such as 1.0, 1.1. or 1.2.
Similarly, two more topics are added to Structure 1: Issues Fixed and 2. Known Issues and respective topics are assigned the taxonomies.
This way a uniform structure is maintained for the Release Notes. The author can easily identify which information should be added under which heading.
Publishing the Content
Let us take an example of Safety messages. These messages are easily managed using taxonomy. All safety messages can be used as a fragment and be arranged in a node (or topic). This one node is used in multiple projects. Only project-specific warnings from the nodes are published using filters.
If we take an example of the Release notes, as per the filter settings, different content can be published for SW releases 1.0, 1.1, or 1.2 from the same structure.
Filter setting 1.0
Filter setting 1.1
Filter setting 1.2
Searching the Content
As there is a large amount of information available on the internet, getting the right information easily is a challenge for end users. However, if the content is classified correctly, it can be searched easily. Users can select the SW release number to filter out the information and they can get the exact information needed.
Managing the Taxonomy
Taxonomy is managed by an Information Architect or a single resource.
Though the technical writers use taxonomy while creating the content, it is not recommended that they manage it. Authors can always request new taxonomies to be created from the Information Architect. This is to have control over the types of taxonomy, uniformity, and ease of management. Before creating a new taxonomy it should be discussed within the group of writers and it agreed on the need, and use of the new taxonomy.
Some requests can be as simple as a new software release number from 1.0 to 1.1.
But some may need a deep dive before finalizing, for example, Region type – Europe, NAM Asia, etc. Technical writers need to justify if the content needs to be published as per the regions and if it will continue to be published in the same manner. It is not a one-time request.
About the Author
In a span of 19 years, Ashutosh Ambike had the opportunity to work with wonderful people and learn multiple things from them. He has worked in the Defence, Factory Automation, Energy, and HealthCare industry. He has done a Bachelor of Mechanical Engineering. After he started working as a Technical Writer, he felt that he was able to express himself better in writing than verbally. He continues his passion for writing in technical publication.
Current Role: Team Lead Technical Communication
Company: Philips
City: Pune, India
No Comments