SharePoint Intranets, Evolving Beyond Department Sites

I admire software application, user interfaces that are built around a purpose. The most popular business application in the world, Microsoft Outlook is a great example. It provides messaging, task management, calendar management, and more. The buttons and menus are organized in a manner that is suitable for sending email or tracking a task. The user interface is intuitive, easy to use, and makes sense.

I think a trend for SharePoint intranet deployments is that they will include designs which are less influenced by content categorization and taxonomy and more influenced by functionality.

When you think of various SharePoint intranets that are being used in businesses today, you might struggle to draw a correlation between the user interface and the functionality. I think that has a lot to do with the fact that implementers are responsible for coming up with a design, a context. I think a common habit among implementers has been to design the applications around organizational structure of the company. When SharePoint sites first started popping up, they weren't much more than web folders for documents, and their main "purpose" was sharing documents as an alternative to a file share. So, the user interface design took on a shape similar to how documents are categorized in a folder share. I think that categorizing documents by department resulted in a trend of SharePoint portals that have a department based design.

I think a challenge now is to recognize where SharePoint came from, that department site designs are out of date, and applications built on it are no longer just HTTP enabled versions of Windows Explorer. We are now dealing with real business applications with real (and custom) purpose. User interfaces need to evolve accordingly.

If you've spent a significant amount of time performing a job function as a SharePoint portal user, in an environment that is organized by department you may have come to the realization like I have that organizing collaborative or actionable content and information according to department doesn't make a lot of sense all the time.

One way to evaluate this is to think about the audience (I mean audience in the general sense) the sites's information is addressed to and what the audience is supposed do with the information. You might find that when the audience doesn't have to "do" anything with the information other than consume it then it might work well in a department site. For example, an announcement is posted to an HR department web site that there is a new employee handbook. The audience simply consumes this information. They are not expected to collaborate and edit the handbook. In this example the department site probably works ok.

Its really when you start getting into information that you are working with when department sites start to fall apart. Collaboration using list items, documents, forms, and workflow occurs around a subject, not around a department. So why try to categorize the information you use to collaborate on, into a department? A SharePoint user who is performing a function doesn't care "who" owns the content any more then they care when it was created. It would make more sense to me if the user interface design promoted what users are actually doing in the system as opposed to who owns the subject matter that the user is working with.