Applying IA in Practice

The field of Information Architecture is young enough for there to still be some debate about the Best Practice. This site has been created to describe the approach that I have used and continue to refine.

All systems have an information architecture but very few have an Information Architect. There are some that believe the topic is either an unnecessary distraction or should be understood by everyone, either group would claim that employing an specialised information architect is a waste of resources. And indeed for many systems this is probably true, however there are enough potential systems which are both too complex to be trivial and too innovative to be well known. For these systems a systematic approach to the shape of the information will pay dividends in the long run.

Of course it is possible to take any Subject Matter Expert and train them in Information Architecture. That is part of the reason for creating this site. However like any new skill this will take time to master and, in my experience the best practitioners have an intuitive feel for the topic that cannot be taught. Unfortunately many consumers of IA inherently consider that since it is easy to use good IA designs it must be easy to create them, and hence it is not worth investing in their creation.

A well defined set of procedures, checks, and tests should mean that an Information Architecture can be delivered with fewer problems and unforeseen complications.

The main practical elements of Information Architecture are:

Uses for IA: An Information Architecture is only valuable when it is actually used
Gathering Data: The practice of obtaining input from Subject Matter Experts about the domain under discussion. This can be to help any element of the Information Architecture from defining the key aspects, populating the model, validating the existing definitions to reviewing the resulting system
Implementing IA: An Information Architecture is only valuable if it is implemented in an accessible form

Implementing Information Architecture

Information Architecture Process

The picture above divides the task into five levels of detail that can be implemented:

Model: Define the domain and the key aspects
Classify: For each aspect define how it is to be classified
Relate: Work out the relationships between the aspects
Deduce: Work out the consequences and ensure that they are acceptable
Exploit: Use the results to influence the system implementation

Each of these must be documented, reviewed with the stakeholders and validated. This usually requires an iterative process, for example an attempt to classify one of the aspects might reveal that the underlying concept is flawed, or a deduction may demonstrate that a classification is too simplistic.

Links to this page

The following pages link to here: Best Practice, Implementing IA, Information Architect, Practice