Does SharePoint Destroy Intranet Design?

by Jakob Nielsen on June 7, 2010

Summary: As intranet projects benefit from powerful implementation platforms, teams should focus on optimizing the user experience for specific organizational needs, as 4 winning examples show.

Several participants at recent Usability Week conferences asked me whether prospects were bleak for intranet designers given the trend for more and more intranets to be built on SharePoint.

It's true that it's less work to build on top of an intranet-optimized system, as opposed to developing an intranet from scratch or patching it together from a bunch of website-oriented tools. But less work doesn't mean no work. And it certainly doesn't mean no usability work.

The basis for all usability is to relate the design to two questions: who are the users and what are their tasks? The answers show how intranets differ from websites:

  • Users = employees instead of customers
  • Tasks = work instead of shopping

These differences are why it makes sense to have separate usability guidelines for intranets and why products such as SharePoint exist. (Other vendors offer similar solutions; I use SharePoint here because it was the most widely used platform among winners of our Intranet Design Annual usability competition. We don't endorse any specific software.)

Intranets Differ

Although there are high-level similarities across intranets, many differences emerge once we delve into the details. As an example, consider 4 of the winning intranets for 2010 — they all use SharePoint, but they don't all look the same:

Homepages of 4 Intranet Design Annual winners. Top row: Huron Consulting Group and Enbridge.  Bottom row: SCANA Corp. and Jet Propulsion Laboratory (JPL)

The differences go far beyond surface characteristics such as color scheme and choice of images. The two bottom intranets have a portal feel, with many widgets on the page, whereas the upper two have more of a homepage feel.

The intranets also deemed different tools important enough to be featured on the homepage: say, a calendar vs. a traffic map.

Let's look at the top navigation categories:

Huron Consulting Group Enbridge SCANA Corp. Jet Propulsion Laboratory
Our People Me & My Career Health, Wealth & Career Employee Center
Our Company Our People About SCANA Tools & Services
Employee Services Policies & Procedures Departments Newsfeeds
Human Resources News & Events Tools & Resources Line Orgs
Marketing & Business Development About Enbridge Our Community Projects
Client Management Application Links   Interest & Work Groups
  Support & Resources   Bookmarks

As even this small sample shows, some navigation categories — such as "About X" and human resources (HR) — are fairly common on intranets. For a bigger sample, see our analysis of 77 intranets' information architecture (IA).

On the other hand, there are also many notable differences. For example, only a consulting company would have a top-level menu for "Client management." And an "Interests" category is more suited to a science-based organization like JPL than many more mundane organizations.

The point is that even this very basic design choice is determined by the organization's nature.

Examining more detailed aspects of intranet design reveals further differences. For example, most intranets have an employee directory, but the criteria used to find employees differ dramatically. Knowledge-intensive organizations often emphasize the ability to find colleagues by their expertise, whereas other types of organizations might deem other attributes more important. Similarly, the information displayed on individual employee profile pages is not just industry-dependent, but also varies dramatically depending on company culture.

Clearly, there are myriad design choices left, even after a company chooses a platform such as SharePoint. And these choices can have a huge impact on employee productivity and the intranet's success.

In fact, the easier it gets to build the intranet's basic infrastructure, the more important it becomes to populate it with the most useful features possible and to create efficient user interfaces for those features. Intranets of the future might require less programming work, but they'll surely need even more user experience work.

Share this article: Twitter | LinkedIn | Google+ | Email