Part 2 of Part II: UX through SharePoint-colored glasses

(Recommended reading: Start with the first part of this rather lengthy post. You’ll be glad you did.  You wouldn’t haved wanted to start Games of Thrones with Season 2, now would you?  Well, maybe if you were a big Ned Stark fan, I’d get that, but… oh, right.)

Believe it or not, SharePoint is designed to be as user-friendly as possible.  According to legend (as well as my own experience browsing their employee directory), Microsoft has a significant investment in user experience designers hard at work on their software products.  If you doubt me, check out a Windows Phone—it’s a better UX than any Android phone I’ve seen, and arguably better than Apple’s.  (Why?  We’ll discuss that in a future post.)

That said, Microsoft is designing products that are meant to be versatile and adaptable.  SharePoint needs to work as well for the hometown insurance agency down the street as it does for multinational conglomerates.  Essentially, Microsoft accomplishes this by shipping SharePoint in what we can truthfully consider a template format.

It’s there from the moment you finish the install wizard—it’s got all of the functionality and features you need—but it’s blank, and just waiting to be filled in with your own specific information/branding/thinking/working.

The true SharePoint professional acknowledges this—admitting the UX limitations of “out of the box” or “naked” SharePoint—and accepts that any solution will need some configuration and development time to truly meet the needs of the audience (or more often, varied audiences).  At the same time, there are notable features native to SharePoint that truly enhance the experience of any user.  I’m personally partial to these three:

• The Ribbon interface.  Love it or hate it (and most people who hate it were just too used to Office XP), it provides a consistent UX for users of Office, which is even more widespread than SharePoint.  In its most basic form, if you can edit a Word doc, you can edit a SharePoint site.
• Integration with Lync Server. Wouldn’t it improve the user experience, you say, to see someone’s name attached to a document or article on your screen and, needing an answer or having a comment, you just call their phone up from your laptop?  Well, you can do that from SharePoint.  OOB, baby.
• SharePoint Search 2010.  SharePoint 2010 intranets provide specific, on-point search results that can be refined and filtered for even more flexibility.  I have better luck on a SharePoint intranet than I ever had doing internet searches with Google.com.  (Full disclosure: I use Bing now.)

As I said, these are just three of my own favorites, but there are others.  SharePoint has a lot of great tools that can be leveraged in building a solid User Experience.  You just need to (a) know they’re there, and (b) how to leverage them.

Navigating Around the Barriers

With all of that said, on both sides of the coin, still the biggest impediment to SharePoint usability is SharePoint itself.  This platform, as much as I love it, just does too many things and offers too many options for potential users to digest at once.  Apple may not have invented the concept of simplicity, but they’ve surely hammered home its importance as a fundamental principle of making technology useful and easy to understand.

When approaching SharePoint with the intent of providing a good user experience, it’s essential to accept that it will never be a simple, single-use application.  It can certainly be a collection of simple, useful apps bound together by a common framework.  That should be the goal of the User Experience Designer and the SharePoint Architect alike—creating a solution that works for everyone, easily, but provides specifically tailored services to many different personas and scenarios.

That’s a reasonable goal—as long as you understand both sides.

Tune in next week for what’s sure to become Hermione Granger’s favorite blog post, SharePoint UX: A History.

Both Sides of the Coin (Part 1 of 2)

Welcome back!  In my last post, I introduced the topic of user experience (UX) in SharePoint, and spent a little time explaining why it’s so important.  Today, as part of this continuing series on SharePoint User Experience (SPUX? Can I call it that?), I’m going to explore some different perspectives for approaching this topic.

I’ve never been one for blindly following crowds, myself.  Whether it was rejecting grunge-and-flannel in the 1990s (at the drop of a pin, I can still give you twenty reasons why Blur were a better band than Nirvana) or my stunning record of never having voted for a victorious Presidential candidate, I’ve always been a bit of a contrarian.  SharePoint people aren’t typically UX people, and UX people typically have little or nothing to do with SharePoint people.  This sad set of circumstances is unfortunate and worse, impractical.

I base my own approach to SharePoint User Experience on two fundamental principles:

1. User Experience is Humongously Important. (We discussed this last time.)
2. Two-thirds of the Earth is covered with water, and the rest is covered with SharePoint.

Translation: “Like it or not, SharePoint is everywhere, and it needs a sound UX to function well.”

With this in mind, let’s consider two similar-but-distinct ways of viewing the situation.  It’s just looking at both sides of an issue.  We can study SharePoint from the perspective of a User Experience professional—but conversely, we can also look at User Experience from a SharePoint-centric point of view.

Neither is wrong, and neither is right, but if we can do both together, we stand a much better chance of being able to move forward and actually create superior user experiences on the SharePoint platform.  Let’s start with considering SharePoint through the UX lens.

SharePoint via UXD Glasses

In the world of software design, traditional user experience professionals are platform- and technology-agnostic.  This is generally a good thing, because it gives them a mandate  to focus on what’s important in ground-up user-centered design—human behaviors, and how a system might best respond to them—as opposed to working with a set of known, prescribed features and designing interaction around them.

Unfortunately, we neither live nor design software in a perfect world.  Starting a SharePoint project with the Platonic form of an intranet is about as realistic as getting through four years of college with all of our so-called Platonic friendships (e.g., those with the opposite sex) intact.  Translation to the colloquial: It ain’t happening.

The UX designer who works with SharePoint will need to assume certain truths about the platform he or she is dealing with.  Lists will always remain a foundational element of how data is structured, for instance.  Library services (document check-in and check-out) can impede collaboration but enable firm governance.  Flying monkeys will come screeching out of nowhere when you least expect it.  Et cetera.

The thing that makes SharePoint so great– its versatility– is also its own worst enemy because left alone, it lends to complexity.  A solution that, like some kind of business-friendly Lego set, can be endlessly configured to meet different sets of requirements can seem like both a blessing and a curse.

It can be tempting to see some of these foibles of SharePoint as roadblocks to a functional UX.  Truthfully, some of them will be if you leave them alone and trust a naked SharePoint UI and some cursory user training to be enough for a usable solution (they’re not).  Yet by cleaving to certain principles of good user-centered design, it’s possible to turn a SharePoint solution into a very user-friendly place indeed.  A good UX professional knows this, and will be of great help when you’re building your new-fangled audience-engaging socially interactive intranet version two-dot-oh.

This post is continued with UX through SharePoint-colored glasses.  Just follow the link.