Use a Process to Develop an Information Taxonomy

And information architecture design (IAD) focuses on organizing, structuring, and labeling content in a way that supports current processes while being able to adjust to process changes or improvements. The goal of IAD is to help users find information at the right time, in the right format so they can complete tasks and make decisions within a process. Consider this vanilla, sample process and how information supports the process:

In nearly every process task, information is required, including the triggers that start a process. As the process is worked, information is often transformed. When a process is improved, the chances are good that the process will require a different information mix to be effective: some information will be deprecated, some will be new and some will need to be presented in a different way. Sometimes, the user interface will change as well given different information presentation needs of the process. This leads to a potential gap analysis in the following areas:

  • Process flow
  • User interface
  • Reporting dashboards
  • Infrastructure

Processes not only transform data, they also use the data to evaluate how to improve the process itself. As the process is improved, so must the information management system(s) that support the process.

My only point in this post is that if you need to organize your information better, then you first need to document your process and look at the best way to find the information needed at each step of the process. Then work backwards from there – reverse engineer the findability until you deduce the putability of the information – how should it go into your information retrieval system?

Here’s a simple example: let’s assume that your organization uses SharePoint to create phone messages. When someone calls in for another person, sometimes live people take the message instead of voice mail, so phone messages are created. Now, these messages can be written or electronic, but your organization has chosen to make them electronic. And your organization decides to do this in SharePoint 2013.

So, here is the process:

Now, this is an oversimplified process, but one that is worth consideration. Now that we have the process, how do we organize the information for that process? Well, there are two key questions to ask:

  1. At each step in the process, what information is needed?
  2. If we need to find the artifact(s) later, after the process is completed, what metadata would we most likely need to have populated that gives fast, accurate retrieval of the artifact(s)?

As for the first question, in the first step “Phone Call Received”, the information needed is as follows:

  1. Caller’s name
  2. Caller’s number
  3. Best time to call
  4. Caller’s organization
  5. Short message

As for the second step, the “Message Entered into SharePoint”, the information needed is as follows:

  1. Receiver of the message
  2. URL location of where the message should be input

Now that we have this information, if we needed to find this message six months later as part of an eDiscovery process, what information would we look for? Probably as follows:

  1. Caller’s name
  2. Caller’s organization
  3. Call date
  4. Receiver name
  5. Message taker name

If we had these four pieces of information, we could find the phone memo and the exact artifact. So, the metadata fields on the phone message artifact would be as follows:

  1. Phone call message date
  2. Phone call message time
  3. Caller’s name
  4. Caller’s organization
  5. Name of person who took the call

In order to find the phone call message among potentially thousands of phone call message artifacts, we would search on the known information and get a list of existing messages that matched our query. We could then further refine the search until we found the exact message we were after.

So, now you can see how a process can inform you as to how your information should be organized. You simply look at the process, reverse engineer the information needed at each step and then figure out how you would look for that information. In this example, the content itself is also the metadata. In other situations, the content is not the metadata, but the principles offered within this process are the same: look at the process, then downstep into the process the information needed and then finally look at how you would find the artifact(s) and develop your metadata from there. In this way, you can develop an entire taxonomy over time.

Bill English,