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.

Business man at the starting line
A long stretch of technical evolution and a large volume of client solutions shipped in a year.
That is the conclusion I came to when reflecting on the state of Mercury app dev at the end of 2016. The specific things that came to mind were:

  • We embraced the new JavaScript-driven method of developing modern applications
  • We moved to a continuous delivery/DevOps-driven method of shipping software
  • We significantly evolved and modernized our interface construction techniques
  • We incorporated native mobile development into our service offerings
  • We shipped over 50 production applications for clients (and a couple for ourselves)

For the technical leader of a custom app dev firm, that’s a pretty major year. After I got done patting the team on the back because of my newfound perspective on their accomplishments, I realized that a period of digestion was in order. Biting off more new technology was tempting but in the end I decided to go easy on that front – after all, rapid learning and growth is one thing but burnout is another.

My senior staff and I felt that 2017 was the year for us to mature how we build applications, ratchet up our focus on quality and overall become more masterful with our new skills; by early 2017 we had put together a top-level vision along with specific objectives to realize that vision.

In this blog post I intend to share that vision and associated objectives to spark a conversation with other technical leaders and perhaps provide some nuggets of guidance for other leaders of technically-oriented professional service firms (you know, people who build software for end customers not inside their own company).


“Reliably ship quality software that fulfills employees while delivering value greater than its cost”

While worded as economically as possible (without losing meaning) each component of that vision statement delivers a lot of meaning for us. Let’s unpack that a bit:

  • Reliably ship quality software
    In this case, “Reliably” is a bit overloaded – it denotes the need to not only perform dependably, it also means we need to do it across all of our clients and all of their applications. The “ship” brings home the point that committing good code is not enough – we must be able to build, test and deploy that code with just as much alacrity as we code. And the “quality software” clause says we aren’t just pushing out any old thing, we will focus on delivering software that is of value to our clients, is sophisticated code, has an excellent interface and low technical debt.
  • that fulfills employees
    There’s a name for companies that focus on software volume at the expense of employee welfare: “sweat shops”. At Mercury we recognize that only fulfilled employees are going to be motivated to build quality solutions and go the extra mile to do more than just what the client/user asked for. We want the right environment where team members add innovative touches and go beyond client commitments as a matter of course. Therefore, our Vision statement embraces the fact that our work is rewarding and fulfilling to each team member.
  • while delivering value greater than its cost
    In business terms this portion of the vision could be interpreted as “be the low-cost provider” – that is absolutely not the case. We are well aware that there are any number of off-shore and lower-end firms that are willing to build websites and simple applications for a low fixed price; Mercury’s mission is to build premium and complex enterprise applications. This aspect of our vision recognizes the fact that if we don’t provide at least $1.25 for every $1 of client spend, we will not deserve to be their premium partner.

Objectives to Meet the Vision

Mission, Motivation, Objectives word collage

As a follow-up to our carved-out 2017 vision, my entire staff spent time authoring and debating the right objectives to get us from here to there. The team came up with A LOT of material and we commenced to whittle, refine and whittle some more to get to a set of objectives that encapsulated what we really need to focus on. While we agreed that we need to stay on our game that has been successful to date, we need to focus on the following objectives in 2017:

  • Establish base-level proficiency with vanilla JavaScript
  • Unify code approaches and continuous delivery
  • Improve initial product quality
  • Improve ongoing quality of key applications
  • Improve health of Agile planning and sprint activity
  • Provide creative and enjoyable outlets for employees

Establish Base-Level Proficiency with Vanilla JavaScript

Anyone in our industry knows that as a language and ecosystem, JavaScript has begun to dominate strategies, technical direction and developer headspace in the last two years. From the ascendance of JavaScript frameworks like Angular and React to back-end service development in Node to JavaScript-adjacent build tools like Gulp and document databases like Mongo, JavaScript has staked its claim to development mindshare and in a very real way and it has really changed how we build apps.

While we are pretty good at JavaScript, one of the things our technical staff quickly concluded is that we all needed to be REALLY good at JavaScript; our developers and interface designers need to be as second nature with JavaScript as they are with C#, SQL, HTML and CSS. As such we decided we needed to undertake efforts to make sure we have a common baseline level of skill with modern JavaScript.


First, our aim is to analyze the team’s base level skills with vanilla JavaScript using an objective diagnostic test to evaluate competency with basic/universal JavaScript aspects. I expect that many of our designers and developers will “test out” following that evaluation – those team members will function as mentors to developers and designers that do have areas for development with JavaScript.

The following are the baseline JavaScript concepts we want to make sure are second nature to all team members:

  • For loops
  • If Else
  • Switch statements
  • While Do
  • Comparisons
  • Functions
  • Objects
  • Arrays
  • DOM interactions
  • Event propagation
  • Debugging
  • AJAX

While not a particularly daunting body of knowledge, our thought is that with this objective we will ensure a uniform and strong level of knowledge to translate to rapid and effective development in React, Angular and Node along with a common shorthand across the team.

The team will work through online courses and resources targeting each person’s needs. Likely sources include paired mentors, Pluralsight courses and resources including the following:

Developers and designers will meet regularly for Q&A sessions with mentors and help with course work as they work against an assigned JavaScript challenge.


In the spirit of Key Performance Indicators and Radical Focus each objective is paired with a measure to quantitatively and objectively measure whether or not we achieved the goal. The following are the intended measures for our JavaScript objective:

  • Recommended course completion and mentoring participation by all team members
  • Ability to build the spec’d JavaScript-oriented exercise assigned to each team member

Up Next

Our next post will outline our objectives to unify code approaches and continuous delivery as well as improving product quality.  Leave your thoughts below in our comment section and check back often for our next post in this multi-part series.