Monday, July 6, 2015

SharePoint Nirvana Part III: Information Architecture

This is the third installment of a larger blog series called 'SharePoint Nirvana' (links to Part I and Part II) addressing how to make the most of your investment with SharePoint.

One of the biggest pitfalls I see customers go down with any SharePoint related project is focusing too hard on the look and feel, sites and pages, features and functionality they need and never thinking how it's going to be maintained, what the life cycle will be, and how you want users to search and navigate to their content.

Let me transition right into one of my favorite topics:

Designing your site hierarchy and taxonomy

A big part of any good user experience with a SharePoint environment is finding the right taxonomy for your site. Now some people when they hear the word taxonomy might think you're talking about metadata, others might think you're talking about navigation or sites, and even a few might be asking the question right now…Ryan, are you talking about stuffing a dead bird or something? NO! That's Taxidermy. Different blog post and an entirely different author:) But to the others, you're right on the money. In fact, when it comes to taxonomy, my thought process goes to hierarchy and that means hierarchy of sites, of navigation, and of even metadata - such as your content types because really - that's what your sites and navigation are constructed of so they all fit together. That's not all of your information architecture, mind you, but it's a good portion of it. This is the core foundation of any good information architecture.

Why is it so important to the success of your project?

To answer that question, start thinking along the lines of Governance. These decisions impact the longevity, user adoption, and maintainability of your sites. As a consultant, I've spent too many hours helping customers get out of the muddy waters I call "the garbage heap". The garbage heap is a mass collection of some of the greatest ideas all piled together with no through line, no consistent way to tag anything, tons of redundancy, and everything is extremely hard to find. Trust me, you don't want to ever arrive there. So, the short and long of it is that taxonomy is vital to the success of any SharePoint project. Looks like we have a another step in the road to SharePoint Nirvana, eh?

Navigation

Let's start with talking about the navigation. Of all the taxonomy decisions, this is typically an easy one to knock out but may seem daunting at first. It comes early in the project when starting to do usability analysis and drafting wireframes, and it's a huge driver for other pieces of taxonomy. To start determining your navigation, you must first determine - what will your site be comprised of? You don't need to think in terms of any site map hierarchy yet. In fact, at this point, you don't even need to figure out whether content is a site, or a page, or a list item, or something else. You just need to know what they are. Documents, videos, news articles, images, etc.

Next, it's time to figure out how you logically want to group that information so it makes sense to your business. Many companies simply decide to group information as it relates to their own organizational hierarchy. While others group information by their project teams. And still others break down information dynamically based on the user's profile. This is not an exhaustive list of ways to do this by the way. In fact, it potentially may be that the solution is a hybrid of different options. It could be something totally different! My point in outlining these, is that before you pitch your flag in the sand and declare this is your navigation approach, one should always ask themselves these key questions first:

  1. How does your business operate today?
    • How often does your business organization change how it operates?
  2. How do people in your business collaborate?
    • Where would you like to see them collaborate more effectively?
  3. How does any contributing employee of your business determine their tasks for the day?
    • What does every contributing employee share in common with how they work besides just working for your company?

Once you have those questions answered that might change how you approach the final design. Speaking of final, the last items to be mindful of when it comes to your navigation are:

·       Will it be easy to maintain? (going back to mapping to your organization hierarchy, if that's something that changes a lot then it's probably not a good long term solution for how you navigate)

·       Keep the levels of navigation to a minimum (3 is what I recommend to any business)

·       Keep the navigation hierarchy logical to HOW you work, not WHERE you belong (if how you work, is by where you belong then great - but it should not be the driver for how you structure it)

  • Will it be easy to maintain? (going back to mapping to your organization hierarchy, if that's something that changes a lot then it's probably not a good long term solution for how you navigate)
  • Keep the levels of navigation to a minimum (3 is what I recommend to any business)
  • Keep the navigation hierarchy logical to HOW you work, not WHERE you belong (if how you work, is by where you belong then great - but it should not be the driver for how you structure it)

The Site Map

First of all, I list these sequentially so please nail down your navigation decisions before taking a crack at your site map or you may find you need to backtrack. Now, let's roll up our sleeves, shall we?! A site map should start with how you are structuring your navigation but next ask the question:

  • How do you want to maintain this content?

In other words, you need to start thinking in terms of I like to refer to as "containers". These are your storage locations and therefore going to be where content is maintained moving forward. Some drivers for deciding what's a container are:

·       How does the security need to be separated for managing this content?

·       Does all the content you envision simply belong to either a single page or set of pages? Or do you envision many types of content that need to be managed?

·       Is the vision for administrators to manage content in one central location and publish to multiple other locations? Or manage content decentralized, where the content belongs to the area of the site it pertains to?

Answering these questions will help you to determine what is a site, what is just a page, and how deep does your site footprint need to go in order to meet your business needs.

Metadata

At this point you have a true navigation path for your users to get to content and you have defined how the site map is structured make it easy for content managers to maintain. Now it's time to define what kind of content is going to be on your site and how you want the content to be tagged so that it can be easily aggregated to other sites as well as enrich the search experience. You most likely have created a punch list of content along the way as you created your navigation and site map and now it's time to layer on all the rest.

Best Practice

A really great rule of thumb for building out your metadata taxonomy is DON'T TRY AND BOIL THE OCEAN!!! There's so much that can be defined here and what's most important in terms of metadata are two key components:

·       Content Types - not necessarily always the metadata (fields) within these content types but at least what types of content you need to account for

·       Key Site Columns and User Properties - these are the properties about our content or our people that are absolutely necessary in order to display content to other areas of the site (e.g., web parts, search parts, apps)

Remember, search is an evolution that happens over time. It takes users querying over time, adding content over time, and refining results over time to start getting a true analysis of how best to optimize your content and your metadata of your content. That's why I recommend always to layer this on in phases.

Another word of caution, is don't create 100 different document content types. It will do you no good. Out of personal experience, I wouldn't even go beyond 30. So while you may start out with quite an exhaustive list, KEEP ANALYZING and collapse these down until you have a much smaller number. Trust me - no user wants to choose from 100 different content type options to decide which one they should apply their document to.

Finally, I highly recommend getting the content types in your site first and then adding metadata that defines these more later. Determine what the base metadata for a document in your business be and have all the document types inherit from these. This will make it much easier for users in getting started with your site. And it will help you improve search over time rather than trying to encompass it all once.

That's it! You made it to the end of your information architecture journey! (For now)

Thanks for reading and hope this helps anyone out there struggling with this topic. Please stay tuned for future articles that address the other areas on your radar for reaching "SharePoint Nirvana".