I’ve lately been reading some thought-provoking posts by Stephen Fishman over at CMSwire. I think he makes some very astute observations from the UX point of view, and I’d suggest looking into them if you follow this topic. (In fact, a number of his points are exactly the sort of “pure UX” analysis I’ve been working to rationalize with design on the SharePoint platform in my previous posts.) I’ve said before that SharePoint information architecture alone doesn’t make for a good UX. Mr. Fishman gets this.
In his latest post, he studies the need for organizations to balance quantitative and qualitative approaches, and cites the swinging of the pendulum back-and-forth between these worldviews vis-a-vis trends in the tech space.
This is something that has particular value to consider from our SharePoint-specific corner of the universe. Many of the projects I get engaged with (whether through the envisioning, or the actual solution design and implementation) start out with a qualitative driver. Companies want to make certain work functions easier and more enjoyable for their employees, with the understanding that this will lead to efficiencies. If not up front, however, then down the road this vision is usually trumped by the qualitative– aligning with business processes to somehow prove return on investment (ROI) in hard dollars.
As we all know, proving ROI for collaboration tools has always been tricky. It’s only become tougher with the trend towards social computing in the workplace. I really don’t think you can do it, successfully, but these projects still get funded. Why?
They get funded because at some level, the stakeholders understand the qualitative value of this stuff. The problem we run into is when that argument gets outweighed by quantitative factors. There’s always someone looking at the bottom line and wondering whether this solution is worth the cost.
This is where a company like ours comes in; I see it as the duty of the third-party consultant to push for the qualitative, because sometimes clients are myopically focused on the quantitative. As Mr. Fishman says, “user happiness” is what drives engagement. Giving users solutions that work for them will bring them in and get them going with other, related tools.
In a SharePoint world, that means lunch menus, social communities for the flag football team, community events and user spotlights. Users who come in to engage with these are more likely to stay and fill out the form, review the document, or kick off the workflow that gives that quantifiable business value.
It really comes down to balancing the happiness factor (which drives engagement) with and against the business value (which drives budget). In my experience, projects and systems that lean too far towards one or the other inevitably fail to some degree. Use the qualitative to drive for the quantitative. Do your user research (as much of it as you can get in the budget!) and know your audiences. Understand and document how they work, how they think, how they’d like to work, and what motivates them.
Then, when you have to make a case to the man in the suit with the checkbook, present it in a language he’ll appreciate. A quantitative language. Hit him with the facts and figures. Let him know what his users want, and build them THAT solution, not a shoestring-budget naked SharePoint site with a nice taxonomy.
