When cleaning up network drives, you’ll need to organize documents into a new environment. The problem is too many companies end up creating an information architecture disaster.
There are two principal ways to avoid this:
Many of our clients are cleaning up network drives and pushing business users to embrace tools like Box, Office 365 or other similar tools. One of the goals that organizations have with a network drive clean-up project is to improve search capabilities for office documents.
That means that organizations also have to start thinking about how to organize those documents in a new environment—an effort that’s formally known as information architecture. If you aren’t careful, this re-organization can turn into a big mess, with a significant negative impact on the user’s experience.
In this post, I’m going to discuss a couple of the biggest mistakes I’ve seen organizations make and try to offer some quick solutions.
The biggest mistake, and the first one that organizations will commonly make, is to ignore the business. Migration projects of every type end up running behind schedule.
Important tasks like information-gathering, design and change management are often the ones that take the hit. This can happen at the expense of the important work of actually getting a system up and running and moving data or documents.
Even when a project isn’t behind schedule, many migration teams assume they can “infer” the best taxonomy or information architecture, based on how documents were named and stored in the previous system.
This is bad for a couple of reasons. First, it ignores the fact that legacy environments have a life of their own. In many instances things like naming conventions and file trees have been set up in ways that don’t make technical sense and might only make sense to the user who created them—in all likelihood long, long ago. Second, it ignores the fact that users themselves are generally not good at developing systems of organization in the first place.
Quick solution: Talk to the business users! But don’t ask them what they want the file plan to look like or how they organize documents today. Instead, ask them to tell you about their most important documents and what’s important about those documents.
Here are some things you can ask: Do business users need to know the date associated with a document? Maybe the client it is related to? Do they really need that information on every document, or is it just nice to have sometimes? Those types of questions will give you foundational input for building an information architecture.
Another common mistake, especially for teams that haven’t previously created an information architecture, is to conflate or confuse the purpose of what they are creating.
Every system needs two types of organizing principles: One manages the document at a database level. That describes what the document is, how it should be managed, and what its relationship to other documents is. This is typically expressed as a hierarchical taxonomy.
The second set of organizing principles is focused on how users search for documents. It doesn’t matter if we’re talking about navigational search (i.e. clicking on folders to find a document) or teleportation (i.e. using a search bar).
The way a user looks for documents is different from how a system organizes documents. There might be overlap between these two approaches; but ultimately, they are different and should be treated differently.
There’s a quick solution I’ve hinted at already. The solution is to develop a document taxonomy that does two things: helps with the technical implementation of the system and provides separate information architecture to assist end-user search. The taxonomy will typically be pretty rigid, while the information architecture for search often takes more of a faceted approach.
It’s true that migration projects are large-scale and often run over budget and over schedule. But the impact of developing good information architecture is huge for both the operation of the future state environment, as well as end-user acceptance. It is well worth the time and money to make sure that you get both of these right.
For more on our thinking on this topic as it applies to Office 365, check out James Watson’s post, “O365 Migrations: Taxonomy Development Simplified.”
To keep informed on this and other related topics, be sure to sign up here for Doculabs’ quarterly newsletter.