Information Architecture in SharePoint: One Size Does Not Fit All3 min read

Introduction

"One size fits all" doesn’t work for Information Architecture.

Especially not in SharePoint.

In a previous post, I discussed a lot of bad SharePoint implementations are due to bad Information Architecture.

As a general rule, if your users complain that they can’t find the information they need, it is most likely because your Information Architecture (IA) needs tweaking.

Your IA may have been great when it was first implemented. But things change.

Your customers’ needs change, and your business needs to change to adapt — if you want to stay in business.

When your business changes, your IA should change as well.

In this article, I’ll discuss how to avoid the "One size fits all" approach for IA, and how it should constantly evolve.

IA does not equal the Org Chart

The first instinct when building an IA is to mimic your company’s Org Chart.

That would be good… if your company suddenly became sentient and started browsing your SharePoint site. If Contoso Inc became a living thing, it would feel right at home navigating an IA that looks like its Org Chart.

But you don’t build IAs for companies.

You build them for people.

Your SharePoint users are those who will need to find information. They’re the ones that need to be able to get to the stuff they need to do their jobs.

So, here is my bold statement:

Information Architectures need to be User-centric, not Organization-centric.

Now many of you are probably saying: "Do you expect us to build different navigation for every single person in my company?"

Ideally, yes! But it isn’t as simple as that.

And how do you fit different navigations for every user in your IA? Won’t it get too complicated to make sense?

Limitations of file structures

In the olden days, when people tried to build IAs for network file shares, there was only one dimension to work with. The folder structure.

With folders, if you want to create a folder structure that caters to different types of people, you don’t have a lot of flexibility.

Let’s take an example: employee benefits.

Most organizations offer various types of employee benefits. Here are some examples:

• Health care
• Retirement
• Workplace flexibility
• Wellness program
• Tuition reimbursement

The Human Resources department handles some of the benefits above. Finance department handles some others.

When creating the folder structure, you want to give a place for our HR folks to share benefits information. Things like brochures, forms, standard operating procedures (SOPs), etc.

But you don’t want people from the Finance dept to mess with HR’s files. And you don’t want HR people to mess with Finance’s files.

So you create another folder for the Finance department to share information about the benefits they take care of. Another folder with brochures, forms, SOPs, etc.

But how do employees find information about benefits if all you have is a file folder structure? They need to know that there are files in both the HR and Finance department benefits folders.

That’s the problem with using a file folder structure. If you don’t want to duplicate documents, you need to put them in one place.

So you end up creating the lowest common denominator structure that will cater to most people.

But what if you could use more that one Information Architecture?

To be continued

As it turns out, your SharePoint Information Architecture has 3 different dimensions! That’s 3 different types of Information Architecture at your disposal.

In our next article, we’ll discuss the 3 dimensions of Information Architecture in SharePoint.