How to come up with metadata?

So, you are sold on the idea that metadata is the thing and absolutely want to implement it in your SharePoint environment. Moreover, you know how to set it up as well. You are just about to convert your nested folders into magic metadata. But here is a challenge. How do you know which metadata properties your users will need? Which columns do you create? Moreover, what are the drop-down choices for all the columns you plan to create? It might be an overwhelming task indeed. In this post, I would like to alleviate your anxiety and give you some tips that will help you get started and help you come up with metadata. These are not some theoretical tips, they are actual techniques I use with my clients when I help them migrate from folders to metadata.

How to define metadata?

Tip # 1: Look at folder names

If you are planning to migrate from folders to metadata, your # 1 clue is right in front of you, in … folders. Folder names to be precise. Take a look at how documents are organized currently and how users name the folders. This will be your metadata. For example, if you are migrating client documents and your users are organizing files by putting them in top-level folders with client name and subfolders with year, all of the sudden you have 2 columns of metadata defined for you. Do this for all the subfolders, evaluate the structure and naming convention used and see if you can pull additional metadata ideas as well. Even for some deeply nested folder hierarchies, you can pull some common properties/metadata.

Tip # 2: Look at file names

File names can also be a clue. Sometimes users try to build in some “metadata” information into the filename. For example, you might see a file called GoogleInvoice20160629.pdf. From that filename alone, you can extract the Client Name (Google), Document Type (Invoice), Date of the document (June 29, 2016). See if a similar or identical naming convention applies to some other files as well. All of the sudden you have several metadata columns to work with.

Tip # 3: Ask yourself: How will you search?

I call this an Amazon Shopping approach. Say, we are shopping for shoes. When you go to an Amazon website and start shopping, how do you search for them? Well, I am sure you are looking for a particular brand of shoes, color, size. All of the above are metadata properties of the shoes. Because Amazon knows these parameters are important to you, they built mechanisms for you to filter and sort on them.

The same exact concept applies to document libraries. Say, you have hundreds of company policy documents. If you are searching for a given policy document, how would you find it? What criteria will you want to filter or sort by? May be things like a policy owner (i.e. HR or IT) or policy renewal date (January 2017 or March 2018) would be important as they would allow you to zoom in on a handful of policies and sort by renewal date. Hopefully you get the idea. Make sure to not overdo it with metadata. Limit yourself to the properties that are truly important or will be used in search. For instance, in the shoe example, every shoe has a country of origin (where the shoe was made), but consumers never search by this field, so that’s why it is not available for you to search by on Amazon website.

Tip # 4: Use Enterprise Keywords

If none of the previous tips were helpful, it might be a good time for you to find a wall and bang your head against it. Alternatively, you can also offload the exercise of Metadata definition to your … users. That is possible with the functionality called Enterprise Keywords. I have written a very detailed blog post to explain what these Enterprise Keywords are all about and how they can help you define metadata. Check it out here.