What UX implications should I be aware of when designing an enterprise website/intranet on SharePoint

16 Jan 2012 - 4:42pm
4 years ago
14 replies
4400 reads

We are currently weighing up the for-and-against in relation to whether to use SharePoint or an arguably better suited ECMS.

I am looking to gather compelling evidence both for and against SharePoint in relation to how it will effect usability, accessibility, the user experience and designing the UI.

I want to hear the word from the trenches, what have you succeeded and battled with. If you are able to backup your story with evidence and statistics all the better, but really I just want to hear from other UX folk on designing customer facing enterprise level websites and intranets with SharePoint.

Thank you in advance.


17 Jan 2012 - 10:13am

Just watched a Fortune 500 client struggle with Microsoft and their build partners to create a global enterprise CMS-driven website. 6-7 months in it turned out Sharepoint was totally incapable of delivering on many common object-oriented, tag-driven, rules-based dynamic web mamangement syste. $100,000s  totally wasted.  Adobe CQ5 could do almost all of it out of the box with configuration, not development required. Sharepoint also could not deliver on the desired faceted search.

Over the years I have found that Sharepoint is much less capable and flexible than Microsoft or their build partners claim.  My advice? Run (Hell, sprint!) away from Sharepoint for something more capable. (Like Sitecore for .NET or Adobe CQ5 for Java).

Specifically Sharepoint could not

  1. handle multiple instantiations of a kernal "standard" site to support multiple countries and mutiple business units
  2. faceted search
  3. sharing of content across instances
  4. complex taxonomies and tagging
This was with Microsoft's biggest build partner and supposed Sharepoint experts to boot.

17 Jan 2012 - 4:47pm

Thank you Jon, these are great insights and your specific list of items that SharePoint couldn’t handle will be very helpful. Do you know if this would hold true for SharePoint 2010 too?

17 Jan 2012 - 11:27am
Kivi Shapiro

Hi Jon,

This is very relevant to a project we're working on now. Can I ask if it was the full SharePoint 2010 Server they were using?


17 Jan 2012 - 4:48pm

Good question Kivi, I would also like to know this.

19 Jan 2012 - 12:28pm

I second Jon's comments.  I also have horror stories about the way Sharepoint handles search and taxonomies.

19 Jan 2012 - 5:39pm

Karin, if you are able to elaborate on this further and provide us with your first-hand account that would be excellent stuff.

19 Jan 2012 - 4:19pm

It was Sharepoint 2010.

If you have a globe-spanning company with a multitude of business units offering a wide offering of products and services you really need an extremely flexible system -- preferably one that is object-oriented from the ground up using tagging and multiple taxonomies. That is not Sharepoint. The best solution I've seen so far is Adobe (nee Day) CQ5. You can describe an object by tag values with the object connected to branches of more than one taxonomic tree. Try to do that in Sharepoint.

With users using search as their default reserach method (and bearing Pirolli'sapplication of Charnov's Minimal Value Theorem) to how users find information a faceted search system starts to look like a valid option as the main navigation. Again not Sharepoint's strong suite.

Despite MS PR Sharepoint is best used for internal document management. It is not designed to be highly flexible, nimble or freindly. Sharepoint may be OK for an  Intranet or simple website. Sharepoint also has a strong positive in the huge number of pre-existing plug-in modules and a sizeable number of developers/partners supporting it. Finally, Sharepoint is natively supportive of a .NET infrastructure which is very popular with enterprise level IT folks.

CQ5 for example is Java-based. It can work in a .NET world but not as a native.

Sharepoint 2010 is not a bad product, but MS and its partners oversell it like crazy for very inappropriate projects. 2010 has also decoupled Sharepoint the engine from thee front end. This allows you to use an alternative publishing system -- either off the shelf or purpose built.

If you need to share content between instances, update content across instances from a central "master" source or need powerful rules-based dynamic web publishing I would say look elsewhere -- that's not Sharepoint's gig.


19 Jan 2012 - 5:37pm

This is great stuff Jon, fantastic insight. I really appreciate you taking the time to expand on this further.

20 Jan 2012 - 8:42am

Totally agree with Jon. I was in your boat a year ago, except I had no choice but to work with SP (2010). I'm never working with that again. Search for perspective on this site and others, advice is the same: run away. And if you don't run away, make sure you allocate for 3x the normal rate and/or time, because SP makes everything 3x harder - design, development, and hardware reqs.

How about an example: typical design task - differentiate different kinds of hyperlinks. In my case I wanted usernames/authors to stand out as cyan with generic and numerous article links being some neutral color - dark gray. You can't do that, sp won't let you in any of the ootb webparts. You have to roll your own from scratch. So you either a) live with every single link being the exact same class everywhere or b) invest in dev time building the feature from scratch in javascripte/.net/asp/etc. The kicker is that the same mentality pervades the system (Jon gave the technical reason: a total lack of rational OO practices). You can't modify, you can either use ootb or go rogue. There is no middle ground. 

I could go on. Taxonomy and tagging is minimally useful at best and actively wrong for (arguably) most use cases. Search is pretty much Explorer search - good for some meta information on uploaded documents and slow as hell. We built our own filter webpart in javascript to display real time results (this was apparently revolutionary - "Clicking on things on the left made stuff on the right happen! You did that with *Sharepoint?!" Accessibility and graceful degradation were not something I could afford to contemplate). The other ootb search features we left in (people search is actually not bad) caused problems from a visual standpoint: the css is so baroque that I could not make the "two" searches look the same pixel for pixel because of the way SP handles masterpages and inheritance. Speaking of masterpages: SP Designer 2010, a free product advertised as a great way to get designers involved in SP projects, used to once upon a time be FrontPage.

In conclusion: projects can cost hundreds of thousands of dollars, even a million and up, for something that could be built by a tiny team of smart jr folks and Wordpress for a fraction of the cost. The only reason to use SP is if your office lives in MS Office products, wants to version control some of them slightly less retardedly than ad-hock server share folders, and have a shared vacation calendar. Oh yea, the Silverlight org chart plugin is snazzy for users for the first 2 minutes. (There are a few others, but designers aren't part of projects like that, normally).

20 Jan 2012 - 4:48pm

Brilliant, thank you for your account Julie. If we do decide to use SharePoint 2010, from what I have heard we would be looking to go rogue (I like that terminology!) and roll our own UI from the ground up. If anyone has experience of doing this I would like to hear your accounts and how this worked out. What were the difficulties and barriers to building your own? I can only imagine there are plenty of constraints to work within. I would really like to get a handle on this too.

20 Jan 2012 - 9:18am

Thanks Jon and Julie,

Details and real-world implementation experience are greatly appreciated.


20 Jan 2012 - 4:24pm

I am not an apologist for SharePoint however do feel that the tenor of the direction of this thread puts the blame in the wrong place. "The fault, dear Brutus, is not in our stars, But in ourselves" (and the software company evangelists and/or agencies that deploy the software). SharePoint (2007-2010) is like any other Microsoft software that comes featured laden with the idea that the company will determine which features best address the issues within the corpus. OOB is suboptimal and meant to be; the point of enterprise software like bespoke clothing, is tailoring to the enterprise.

I have worked for agencies that have done no configuration for SP search, one of the most configurable and sophisticated search engines available. Most clients have serious search issues and SP can address most of those if a user-centered approach is applied. This means having a search IA/UX involved from the outset.

The biggest issue that I've found is that the enterprise assumes that the agency will configure search. The agency promises to do so and assumes that the UX professional will do it. The UX professional does not know enough about search and so assumes the developer will do it. The developers spend their time scraping knuckles trying to get the system set up, doesn't have the information to custom configure search and...no one told them they were responsible for delivering the Google experience without Google.

The most successful path is one that analyses stakeholder/user behavior, frustrations and expectations, maps specific features to these, configures specifically to enterprise constraints and culture, measures and refines. Yes it takes time, yes it involves some custom development and yes, your mileage will vary. Like any content management system, getting it up and running is no walk in the park. SharePoint is no different.

I am sorry that you had a bad experience with SharePoint. It can be a very good product. And, it is not too late to get the search working right for you, your colleagues and your collections. Like Jessica Rabbit, SharePoint
2007/2010 is not bad. It is just drawn that way by an incomplete deployment strategy.


p.s. Julie, I am surprised by  your link issue as it seem antithetical to common UX practice that would discourage using color to distinguish links for user types due to a large contingent that are color blind. Perhaps SharePoint was saving you from this or I misunderstood what you were trying to achieve.

20 Jan 2012 - 5:16pm

Marianne, thank you for your measured and well structured argument, I side with a lot of what you mention here and I, as I believe so do you, feel this is endemic of all CMS. As I mentioned to Julie, if we decide to use SharePoint for more than document management, it is a safe bet that we will be rolling our own UI and I can say for certain that we will be taking that which you describe as the most successful path.

Now, I have a strong suspicion that you have tackled SharePoint in the past (or an equivalent) and have experience of crafting your own UI within it, overcoming pain-points and working to its constraints. I would be extremely interested to hear from you on this.

Lastly, I am not sold on Julies link issue being antithetical to common UX practice. I believe Julie added some valuable insight in to types of issues that must be overcome. In using different colours for user types, as long as correct semantic information is integrated, alongside further accessible text, use of colour in the manner suggest is okay IMO. Just make sure that grey text meets WCAG 2 contrast levels Wink

25 Jan 2012 - 9:02am

The link color was an example of a trivial thing to do for the purpose of demonstrating SP's inability for object selection, and I apologize if it wasn't the best one. Substitute any other css-available attribute you like, or Javascript for more sophisticated goals. As for the specific concern of accessability, my example was cyan and dark gray, which is just as much a value shift as a chroma one. The goal was to differentiate between different sets entirely rather than elements of the same set, in which case I completely agree that color and value is not the best way. Btw, there would be no way of adding further accessible text for specific elements for the same reason one cannot change colors: SP just doesn't give you access to built-in objects/variables. In a block of, say, users, articles, and tags (ex: Mary Jane classified "My Favorite Pony" as fiction) the only thing you can do is change the div's child hyperlinks. All of them or none. 

The above problem is, from my experience, most true with the MySite bits. I use it specifically because social features are a popular topic and selling point.

Marianne, I think your other point is also interesting and illustrative:

The biggest issue that I've found is that the enterprise assumes that the agency will configure search. The agency promises to do so and assumes that the UX professional will do it. The UX professional does not know enough about search and so assumes the developer will do it. The developers spend their time scraping knuckles trying to get the system set up, doesn't have the information to custom configure search and...no one told them they were responsible for delivering the Google experience without Google.

Who should take responsibility for this quagmire? To continue with the search example, consider the premise that users expect not much less than Google and at a certain point of underperformance (or different performance to be more accurate) would actually be irritated with the product because it deviates from their everyday behavior to such an extreme extent. Irritated users are obviously undesireable, and the designer is expected to anticipate such negative reactions and design something different/better. One could build visual and behavioral clues that teach and prepare the user to expect a different interaction, but SP UI modification is far from easy. Simply skinning SP isn't bad, but as soon as you start fiddling with layout and visual hierarchy, not to mention more sophisticated context-driven UIs, then watch out.

I don't think SP search is entirely horrible and has some useful features, but I do think it misrepresents itself by advertising more speed and power than it has and looking like something it isn't, and that's the problem. With Sharepoint, there are just so many of these kinds of traps, and by the time a new team figures out what they are, they've burned through a sizeable chunk of the budget. 

Syndicate content Get the feed