There was an interesting Tweet earlier from Richard Harbridge regarding the effect of SharePoint on intranet design. The article pointed out several interesting points regarding the complexity of developing on an intranet optimized platform. But while the platform itself has certainly been optimized to support the scope and scale of intranets (both large and small) the platform itself really needs to be tailored to meet the specific needs of the business.
Does SharePoint Destroy Intranet Design? http://bit.ly/95tKhB— Richard Harbridge (@RHarbridge) June 7, 2010
One of the things that a lot of SharePoint implementations lack is a true understanding of how the front end of the SharePoint intranet/portal is going to interact not only with the various backend systems you’re trying to bring together, but almost more importantly with the business process itself. Sure it's great to put the latest and greatest technologies in front of your end users, but until you truly understand how the end users are going to be interacting with the environment it’s virtually impossible to develop an effective, usable intranet.
When it comes to SharePoint, this is (in my opinion) where we see the biggest level of change; the shift in methodology in how we think about what we’re developing. We’re not “destroying” intranet design, but rather turning it on its end; looking at it from the point of view of the end users. Five years ago we'd be focused on where all of the data is and how to bring that data together, leveraging the power of technology. Today that power extends far beyond the bounds of simply displaying data, offering an environment rich in collaboration (let's not just show the user some data, let's let them interact with it). How does Joe Bag-of-donuts interact with this, how do we trim the waste out of the process he’s following, and how do we streamline the communication and flow of data from the publisher to the end user (let's not forget the power of lean thinking, especially when you're trying to justify the cost of your proposed shiny new portal to the bean counters).
In your traditional intranet environment that "publisher" is historically a few defined groups, maybe the communications department for example. In the SharePoint powered intranet world, Joe Bag-of-donuts himself can easily author content (still requiring authorization by the communications group before publishing), or create a rich dashboard to share with his specific team or work center. It's this fundamental shift of looking at things from this "new" perspective, and actually empowering the end user to make decisions that's ultimately redefining how you develop for the corporate intranet.