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:
- Talk to business users about which files are important—and why.
- Fine-tune the user experience independently; it's not the same as building the right information architecture.
When cleaning network drives, many companies also must improve their document search capabilities.
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.
Don't ignore business needs when you clean up network drives and migrate content.
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.
Pay attention to information gathering, design and change management.
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.
Why it's not a good idea to guess at the best information architecture.
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.
Ask business users to tell you about their most important documents.
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.
Don't confuse user experience with document management.
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.
Organizing principle #1: Hierarchical taxonomies.
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.
Organizing principle #2: Know how users search for documents.
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.
A document taxonomy should help with the technical implementations and assist in user search.
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.