Share and Enjoy !

Excerpt from “Creating an Award-Winning SharePoint Intranet” white paper – download here.


One of the things everyone and I do mean everyone struggles with when it comes to establishing a portal is striking a balance between two very high-level roles in a portal – consumers and producers.  At the most basic level, users are either consuming content within the portal or they are producing it through their contributions.  Much like the chicken and egg problem, you will find yourself trying to decide whose needs are most important and whose needs should be satisfied first.  There is no right answer, and it is a delicate dance that will require attention and tuning over time.

By keeping it clean, I’m suggesting constant attention to reducing the clutter and glut of information so you can keep your consumers happy.  You will have the desire to present all sorts of information in your portal.  And you are likely going to want it all on the home page of either the portal or on the home page of a specific area of your portal, like the HR site or the IT site.  It makes obvious sense to want to put everything where you know the eyes are going to be.

Beware of Information Overload

However, nothing can overwhelm and scare off your users like information overload.  Landing on the home page with 12 distinct pieces of content being presented, all with competing goals can result in a user never consuming any of it.  Think of your portal like an iceberg and at any time a user is only seeing the part that is above the waterline.  Even though there is a mountain of content that is floating just beneath the surface, they are never overwhelmed at the enormity of it all.

A key tenet to making the iceberg approach possible will stem from how much time you invest upfront in defining your site structure and pages.  If your site structure is defined properly, it will allow you to easily decide which portion of the information iceberg a user can see at any given time based on their location.  This sort of browser-based context for content presentment is a key aspect in the usability of any portal.

Favor Simplicity

In addition to keeping it clean, I always favor simplicity in everything that involves your end users- whether they are adding content or just consuming it.  With all the features that SharePoint offers, you can easily find yourself getting wound up and establishing rules that can stifle contribution and, in turn, lose consumers due to lack of content.  I’ve often found myself referencing the phrasing Bill Gates used in 1996 “Content is King.”  My real take away from it is a drive to empower users to contribute and reduce the friction to that contribution in any way possible.  Without content, there is no portal!

If you are new to SharePoint or content management systems, I suspect that my reducing friction mantra is one that may have you scratching you head.  Reducing friction comes from careful thought about what you are asking contributors to do or provide to make content consumable by others.  In SharePoint when users upload documents, you can require them to tell you as much or as little about what they are uploading in the form of metadata.  For example, you can ask for the department that “owns” a document or the type of document it is based on some pre-determined taxonomy.

Many times, the knee jerk reaction is to force a user to tell 5, 10 or maybe even more unique things about a document.  Such a barrier (or friction) can deter contribution.  Absolutely every required thing you ask about a document should be considered with an eye toward what downstream value it will provide.  Search, process automation and other downstream impacts are just some to consider.  However, if your answer is just because it seems like it’s nice to know about the document, you are probably better off not asking for it.

SharePoint to Reduce Friction

SharePoint has an often overlooked and extremely valuable option that can help reduce the friction for your contributors yet still add value for things like search.  It is called automatic metadata, and its value comes from being able to automatically tag documents with metadata simply based on where they are located.  Again, I would refer to the importance of a well-defined site structure which becomes an enabler for this automatic metadata.  Take my requirement for the department that “owns” the document for example.  This could be automatically set just by uploading it to a specific department site.  Consumers get much desired findability when searching and contributors aren’t slowed down to provide a department.

Share and Enjoy !

Related Content: