A SharePoint Consultant on Information Architecture

A SharePoint Consultant on Information Architecture

by Paul Olenick

As a SharePoint consultant,  I find myself often explaining what information architecture (IA) is.  To be more precise, I end up explaining a handful of topics around the subject:

  1. What is information architecture?
  2. Why is information architecture important?
  3. What is information architecture, specific to SharePoint?
  4. What is the difference between information architecture and information management (IM)?
  5. When should information architecture be addressed?

In this two-part series, I will attempt to answer these questions with two goals in mind:

  • For those new to the concept of IA, provide an introduction to core concepts. 
  • For the more initiated, provide a framework (a checklist?) or at least a starting point to make sure the main points are being addressed in their own projects.

This isn't meant to be fully inclusive but will, I hope, get readers thinking about their own requirements to make sure they've addressed all the areas they need to.

What is Information Architecture?

For an "official" definition a good place to start is provided by the Information Architecture Institute.  They describe IA as "the art and science of organizing and labeling websites, intranets, online communities and software to support usability." 

I quite like this definition.  It truly is a little art and a little science.  But it's a tad narrow. 

Another definition I'm fond of is one I've heard Randy Williams use, which is "your company’s way of describing, organizing and discovering your content."  This is a lot more high level, which I like as it leaves room to include all of the things that make sense in your project.

More specifically, IA tends to include the following aspects of a website:

  • site taxonomy/structure
  • metadata
  • search schema
  • navigation

These are all interrelated.  In fact in many cases, one drives or informs the other. For example, if you're employing navigation that is automatically driven by the site's structure, your site taxonomy will impact the usability of your navigation. 

Further, though I won't focus on it in this blog, a key driver of your IA may be another topic of interest (and confusion): SharePoint governance. 

As an example, imagine a company has created a governance plan, which states that SharePoint sites containing customer data must have auditing and content expiration policies applied to them.  Because these sites represent a small subset of the overall application, it may be wise to segregate them in their own site collection where the policies can be applied, while other sites can reside outside of this "special" site collection without the overhead of these policies. 

For more on governance, I recommend reading A Definitive Guide To SharePoint Governance: Whitepaper by SharePoint MVP Jeremy Thake, Randy Williams, and Richard Harbridge. But for now, this should illustrate the point that governance may impact IA.

Why is Information Architecture Important?

This is a good question.  Why should you care about IA?  Is it just an abstract exercise or does it have an impact on your site's users?  The answer is that it is absolutely crucial, and in many ways.  To name a few:

  1. Usability - Sites that lack a well-thought out IA tend to be less usable.  It's more difficult to find information and site navigation tends to be substandard or confusing.
  2. Adherence to Governance Plan - As alluded to earlier, your IA may be one piece of how a governance plan is executed or adhered to.
  3. Compliance - Policies that allow us to adhere to compliance regulations are quite often driven by metadata.  If the metadata design is lacking, it may be difficult or impossible to stay in compliance, which can have tremendous legal and financial repercussions.
  4. Site Management/Administration - A strong IA will help prevent site sprawl and may help address storage requirements or goals.

Simply put, without an IA in place, your site will be inconsistently tagged, poorly organized, and difficult to use.  And depending on the criticality of your site, this could be either a small annoyance or have much more grave significance.

Stay tuned for part two of this series, where I’ll cover the remaining questions:

  • What is information architecture, specific to SharePoint?
  • What is the difference between information architecture and information management?
  • When should information architecture be addressed?


Paul Olenick (SharePoint MVP, V-TSP) has been dedicated to SharePoint for the past 7 years. Paul has helped clients worldwide solve business problems leveraging SharePoint and shares his experiences with the greater community by contributing to books, blogging and speaking at industry events. Paul is the moderator of SharePoint Shoptalk.
Blog:  Paul Olenick's SharePoint and Search Blog
Twitter:  @olenickSP
LinkedIn: Paul Olenick

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.