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

Question

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.

Answer 1

The primary thing to consider in terms of UX when using SharePoint:

• SharePoint is shitty UX.

That's about it. It's a beast and horrific at most tasks. It does excel at a few tasks, but content management is definitely not one of them and building custom interfaces to accommodate better UX is not a priority of the software toolset.

The only reasons to ever pick SharePoint as an intranet framework are:

• the primary toolset will be team-sites with the primary objective of sharing and storing MS Office documents.
• management bought it and is telling you to use it because, afterall, they just paid 6 figures for the license and don't want to look like the idiots they are.

The only reasons to ever pick SharePoint as an public facing web site are:

• I'm stumped. I can't think of any good reason to ever subject the general public--especially customers--to a SharePoint built site.

My from-the-trenches experience:

I became a SharePoint site/server admin for about a year when the org I was with at the time brought in MS Office SharePoint Server 2007 (MOSS). The CMS I had built 6 years prior was, admittedly, long in the tooth and we definitely wanted something more robust for the new intranet project. And Management had already purchased MOSS, so, there you go. It's what we have to use.

In terms of getting the server farm set up, it was a nightmare of meetings with Senior On-site MS support staff. That, alone, should have been the biggest red flag ever, but we continued to plow through.

My job was to build out the new CMS within SharePoint using a new UI/site architecture designed by a 3rd party ad/design firm.

It took me 6 months of trying to do what is normally trivial things inside of SharePoint. We brought in a great consulting firm that hand-held my attempts. EVERY single interaction with this firm went like this:

me:

I need to [insert some simple task like create a vertical layout for a menu]

consulting firm:

well, you can't do that but here's a hack/workaround/duct tape solution.

After 6 months, I was proud that I had beat SharePoint into submission and I actually got the UI to look like the one the agency had given us. It was, of course, fragile, and basically hacks on top of hacks. The site was also insanely bloated, no web standards, and slow, but that was besides the point.

Then came training. I spent two days getting relatively computer-literate staff up to speed on the MOSS CMS workflow. Why only two days? Well, after two days staff revolted, went to management and insisted we scrap SharePoint and go back to the CMS I had built some 6 years earlier as it was 'easy to use'.

I had to agree with staff.

The lessons I learned is that SharePoint is a standard due to MS's ability to get into the IT departments of large organizations. It's not going anywhere. IF you have to use it:

• hire UI designers that know SharePoint
• don't design a custom UI. Modify existing SharePoint templates.
• realize that SharePoint, at it's core, just makes list of things. Every feature builds upon this list concept.
• Most of the features are features in name-only. (It's not a real CMS...it's Wiki is not a real wiki...it's discussion groups are nothing like normal web forums, etc.)
• To truly customize SharePoint you need to be a .net developer--and not even just a .net developer. You really need to be a .net SharePoint developer. Very few UI/UX folks want to focus solely on that niche (even though it is in demand and pays well ;)

Answer 2

Stay away from SharePoint at all costs if you want a good UI. I am on my second SharePoint project (large corporate IT, 7-figure project).

End users throughout company are reluctant to use it because:

• The navigation is confusing and terribly unintuitive. Everything is 5 clicks deep; and that is if you are lucky.
• It is extremely ugly out of box. I'd like to say SP looks very '98ish but that would be an insult to the 90's. I think they had better UI's back then.
• It is very rigid and does not allow for a high-degree of customization; end users will have to learn to do things the "SharePoint Way". Don't listen to these assholes who say it is great development platform. It's not.
• If you wish to change any of the above, you will need to get at least 3 hacks deep.
• No matter how much hardware you throw at it, it will always be slower than a comparable vanilla ASP.NET site, RoR site, LAMP site, or just about any other site I can think of. When you click a link, or Okay button on a dialog box, sit back and start counting, or go get yourself a coffee.
• Gives new meaning to "bloat". Over 12,000 css classes in SP 2010 according to MS reps that came to our company. So if you think you'll give your site a fresh look by making a few css tweaks, you're wrong. You are going to be fighting with inheritance from who-knows-where, web parts, web part zones, the fact that SharePoint(technically asp.net) likes to prepend the name you give your id's with web control names, guids, and other gibberish you will probably find useless.

I have tried to stick to UI issues without getting into the deep architectural flaws of SP. Lets just say the SharePoint Team has successfully pissed on every basic tenant of good software design. To those who wish to argue that SharePoint is #1 in Enterprise market share and that means it must be good, I give you McDonalds and hamburgers.

Answer 3

That's a big question!

There's no doubt that SP2010 offers a better UX than its predecessors, but any SharePoint collaboration site is still going to be a compromise when it comes to UX and UI design.

The largest issue is the restriction you face when working with web-parts and the baked in controls. This is always going to limit what you can achieve with a design... You cannot edit the code that these generate, though jQuery offers a lot more possibilities for adding css references these days.

Secondly, you have to work within the SharePoint workflow - there are certain patterns and practices, no just for the developer, but for the user too. One of the biggest problems I've experienced with SharePoint is getting people to use it, and take advantage of its (huge) capabilities.

I think the biggest selling point has been and continues to be its integration with other Microsoft products. As a platform to develop for - it offers a world of possibilities, but if you do it half-heartedly then without proper user engagement it will likely fall flat.

If you are not looking to provide a collaboration space that can integrate seamlessly with MS software and services, there may be better solutions out there for you.

That's my stream-of-consciousness opinion, I'm sure others can make better cases for and against though!

The starting point for any SharePoint customisation is always Heather Solomon's blog and custom masterpages. Some will say SharePoint Designer is a must, but I always preferred to hand hack the CSS/HTML in Visual Studio (I spent a solid 3 days once, taking apart the core.CSS and splitting into layout/fonts/colours ... happy times :)

Answer 4

SharePoint accessibility - specifically Section 508 compliance - is severely lacking. There are many pointers to bolt-on accessibility (e.g. earlier efforts at Accessibility Kit for SharePoint (AKS)) and 'more accessible mode' but nothing that from a systems architecture works in anything other than a single server small office implementation.

The default style and templates aren't accessible. A painful reminder of the basics is in every out-of-the-box experience; they don't even have alt text on template pictures. Many of the web parts are not accessible, some are not very usable. Sadly, 3rd party add-ons aren't usually very accessible either.

The best solution is someone who is aware of the issues that can create your own web parts; but if you have to custom develop, that kind of defeats the intended business advantage of using SharePoint.

Answer 5

SharePoint 2010 is actually not bad. At least in comparison to previous versions. I am a SharePoint MCP and .Net developer – so I may be slightly biased – but you can do a lot of really good stuff with SharePoint, if you are prepared to put in the work.

The real problem is that the expertise in building and supporting very cool SharePoint websites is not easy to come by. It can be done (Ferarri’s public site is built in SharePoint, apparently). But, you have to look deeper at whether the out-of-the-box facilities that SharePoint provides make it worth while. And you need a SharePoint expert to help you make that decision.

All of which may make you choose an alternative, which may be easier to get answers for.