SharePoint is an industry standard platform for creating a company intranet, but the out of the box styling leaves something to be desired. Even a well-designed site can fail to engage employees if it isn’t visually appealing. In this blog, I will explore several options SharePoint offers to customize the user experience, and explain the pros and cons of each approach.

For this discussion, I will consider each approach within the context of these factors:

  • Design – how much flexibility does this approach have in creating the desired branding?
  • Effort – how time consuming is the approach and what skills are required?
  • Admin – what implications are there for the future maintainability of the site?

SharePoint WYSIWYG page editor

Colored table displaying Design, Effort and Admin pros and cons
At the low end of the spectrum is using SharePoint’s CMS editor. This allows SharePoint users to easily update text, content, images, and links. Users that have used a CMS such as WordPress or Sitefinity will be comfortable with this solution and can generate pages and content with no technical skills required.

There are two downsides to this approach. First, since content is manually put on the page it is static and requires updating anytime that data should change. This increases the admin time necessary. The remaining methods all rely on SharePoint content to allow the pages to be dynamic.

Second, the out-of-the-box options for styling are limited to what you can do within the WYSIWYG. This approach risks producing inconsistent branding across the site, as each editor makes styling decisions on a page-by-page basis.

SharePoint List WebParts and CSS styling

Color coded table displaying Design, Effort and Admin pros and cons
Leveraging SharePoint content items and exposing them through WebParts is typically seen in many organizations. This approach scores high in both the effort and admin categories. Creating new content types and using WebParts is something business users can easily learn how to do. WebParts are designed to expose the underlying content types which allows the page to be dynamic. The SharePoint List WebPart also allows custom views to be created by admin users to fine tune what data is displayed as appropriate for the context.

To apply branding to pages built this way, SharePoint allows for the CSS to be adjusted. This gives you a limited amount of control over the visual appearance of the site. Company brand colors can be applied, fonts can be adjusted, and similar tweaks can be applied.

The advantage of this approach is that once the CSS styling has been applied, users can continue to use the standard SharePoint editor and WebParts. Any new list created on a page will automatically pick up the styling. This also allows designers to ensure more consistency in branding across the site.

I still score this one red for design because the options available for modification through CSS are limited. A designer with any aspirations of using artistic license will quickly run into the boundaries of this approach.

Overall this is well suited for a SharePoint site where ease of administration is a key factor.

SharePoint Content Search WebParts (with display templates & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
Content Search WebParts allows designers to extend the previous approach while gaining access to significantly more styling options.

Using this approach, designers effectively create their own WebParts that are connected to SharePoint content lists and add them to the site. These custom controls give the designer access via display templates to control the HTML markup that is rendered. The level of effort has increased as this method requires more web design skills than before, but in exchange you get a much more visually pleasing result.

Another advantage of this approach is that with a little training, site admins can learn how to leverage these content search parts. Once they are created, non-IT admins can reuse these controls elsewhere on the site. The pages continue to remain dynamic since the components are still connected to the SharePoint lists.

The obvious question is why the yellow coloring for administration then? Mercury has found through our experience that these components rely on behind-the-scenes indexing that SharePoint does to make the data available to the control. This means that when a new item is added or modified in SharePoint, it will not be immediately visible on the control. Once the SharePoint index process picks up that content and puts it in the index, then it is available for display. In the real world, we have seen this take anywhere from a few minutes to almost 24 hours depending on the site. We have found that even a short delay can cause frustration for admin users who can’t see the immediate impact of their changes.

SharePoint API (with JS & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
For a truly custom branding experience, leveraging the SharePoint API is the way to go. This gives the site designer full control over the markup and allows for the creation of a site that approaches a full custom web page experience in appearance. Additionally, the API is not subject to the SharePoint Index limitations in the previous approach, so content changes are immediately reflected on the site.

From an effort perspective, this is the most complex approach and requires the same set of skills required to do true web development. Of course if the goal is a highly branded site the additional effort will be worth it to produce the desired results.

The drawback with this approach is that business user admins are more limited in their ability to change the site. Future changes to page layout or content types would require changing the code that renders the page. The admins no longer have the ability to reuse the components as they do with the content search web parts. On the plus side this also ensures that the integrity of the site design is maintained.


If you were waiting for the approach that had all 3 boxes green, I’m sorry to disappoint you. As with all implementation discussions, there are always trade-offs. Before selecting an approach, you need to consider your goals for the site, the amount of branding desired, how much budget and time you have available, which skillsets you have at your disposal, and the level of flexibility in making changes. Armed with those answers, my hope is that this discussion will help guide you to select the appropriate approach.