One of the main challenges I’ve had as a “SharePoint Guy” is trying to explain to UI developers I’ve had to work with that SharePoint is a little different in terms of how to control and brand a site and the features we can offer users of the site.

While there are many reasons for wanting to brand a site. If you’re using SharePoint as an Intranet, it helps build company identity if you match the company’s design patterns.  You might want to increase adoption by improving the overall user experience. If company colleagues can have input into how their sites will look and feel they will be more willing to adopt the product.  Custom branding often means the difference between an apathetic user and one who identifies SharePoint as a useful collaboration tool.

In a nutshell, SharePoint branding is a way to change the basic look and feel of OOTB SharePoint in order to give it a more customized or personal appearance.

If we decompose the tasks for branding SharePoint, we can usually define a specific set of features that are important to every use case for branding.

  • Site Master Pages
  • Site Customized CSS
  • Page Layouts/Templates

Now, there are some people who will also add the site behavior (i.e. JavaScript) to the branding deliverables.   Hover effects and animations are as much a part of branding as the site logo.  Branding your site isn’t just about how it looks on paper, it’s how it feels to the user – the “User Experience” as I’ve often seen the term phrased, And of course, the branding of a site is as much a process as it is a finished deliverable. I always cringe when I see a packet of hi-definition mockups tossed over the wall with a note attached, “How long will this take?”

When taking on a branding project for SharePoint, there are a couple of elements to keep in mind as you work through the process:

Maintain Functionality

This is especially important, and one of the reasons that creating a customized masterpage can be a little intimidating.  SharePoint is both and application and a platform and has a lot of baked in functionality and content that will need to be available for the site to function and grow properly.  And yes, the site will grow.  Remember that you are building out a framework for content.  While you may be able to create specific prototypes for specific use cases by hacking up a default masterpage, don’t forget that there are a number of sections that need to be included in order to have the entire SharePoint experience available once the site is live.

CSS classes are another boogieman in the SharePoint world.  There are a lot of CSS classes in SharePoint, not all of them are obvious in their downstream affects. I honestly can’t recall how many times I’ve seen core hacked up to get a functional version of a prototype out the door, only to see that same CSS screw up the formatting or functionality of other webparts that were added at a later date that were not included in the original use cases.  Take the time to research SharePoint CSS and understand what it does before overriding it.

Look For Quick Wins

Sometimes, it really is the little things that matter most. Adding a few navigation icons, drop down megamenus or live-tiles to your site will make it look and feel more customized and improve the navigation experience.  Personalization is key when branding SharePoint, if only to give the user a quick little “Hello ” and maybe display their profile picture.  Sometimes even replacing some of the default site icons with a company icon can make a big difference.

Define A Deployment Strategy

This one gets overlooked a lot during the design and build phase. Think about the life cycle of your site and how often the branding elements are going to be updated.  Is your branding related to a sub-site or are you going to have alternate brandings with sub-sites? Does the site apply to all web applications in a farm or the farm itself?  Will users be able to update the Style Library to add their own customizations for their specific sites?  These decisions will all play into how best to deploy the branding solutions to your sites. This makes a difference on where your branding elements will ultimately reside when the sites go live and can be a nightmare to maintain if not thought about upfront.

In summary, when you embark upon a SharePoint branding project you need to consider the following:

  • How customized styles will be achieved
  • How these styles will be applied to the farm, web app, or site
  • Maintaining SharePoint functionality in all use cases
  • The best strategies for deploying and maintaining these design assets

And ultimately, whatever process you choose, realize that it is a process and while at the end of the day you may have some pretty pictures and mock-ups – they mean little unless everyone has collaborated throughout the process and understood what the user experience is.