The importance of being earnest on usability

I’ve been meaning to write on this topic for some time and I have finally gotten around to it.  We all agree that usability is important, right?  Everyone wants to make it a priority.  You would be hard pressed to find someone at the beginning of a project who doesn’t agree with this statement.   As an “innie”, someone who works inside an organization evangelizing usability to a group of business administrators, I’m finding the practicality of making tools usable even with a broad awareness of the benefits of usability is still a bit of a battle.

Feature mania

The hysteria generated by software products’ new release, development teams and internal staffers about new features is ridculous.  Utter delirium.  Blurry eyed fanaticism.  Features, features, features – “Can it do this?”, “….it should do that?”.   It is truly euphoric to consider the possibilities and quickly all the logical reasoning we have as normal knowledge workers goes out the window, projects lists of “must haves” grow sharply along with the likelihood of project time and cost overruns.

What we all know, once we’ve had time to reflect, is that features are not the be all and end all.  Feature rich is hard to train, hard to implement (lots of testing, long projects), and hard to manage (where to focus quality).  Above all else, project sponsors see features as more value than usability – and make the feature choice when the two are on the table and one has to be lobbed off – instead the decision should be clear, deliver something that brings actual value to this business, not a long list of features, but something that is actually used – that is a true and in my estimation the only measurement of success.

Poor adoption contributes to project failures 

Poor planning leads to cost and time overruns – I think we’ve all read the stats and attribution on project failure  (scope creep, poor requirements etc.).

But poor adoption also seems to play a significant role in project failure.  A recent study of CRM (Customer Relationship Management) systems showed that even amongst successful implemenations nearly half of the companies reported serious challenges with end-user adoption, challenges that often put projects in jeopardy [2].  I don’t have any emperical data (disclaimer: this is my opinion) but I assert that:

	Feature Rich = Poor User Adoption

Particularly when features aren’t directly aligned to business processes.  In professional services, you will see user (sometimes with deep frustration) execute tasks that are aligned to business process (e.g. Time Entry).   Note to professional services organizations – the tools that people can’t avoid (like time entry systems) are in dire need of usability. 

Is this a usability or change management problem?

I think it is probably both - usability is achieve by user centred and participatory design,  by engaging users in usability testing to learn what does and does not work.  It is achieved when labeling, use of common elements such as lists, forms and form elements like check boxes, drop downs are predictable (from a user perspective), consistent (from a user perspective) and accessible (no light yellow text on white backgrounds please).   Great usability lessens the load on change management.  This is evident because there are no user manuals to shop on Craigslist, to read the New York Times or use Facebook.  Just so we are clear I do not assert that usability without change management will solve the technology projects woes of today and in the future – I think that they go hand in hand in fact.  If it is usable but not relevant what is the point, but equally if it is relevant and unusable, then also, what is the point.  I will continue to ask this question for my entire career – who cares what it can do will it actually get used?

To get adoption or achieve a successful change, projects must consider all the processes impacted, account and plan for them, execute a fulsome communication strategy including strategic messaging, awareness and end-user training.  This is a lot of heavy lifting – a lot.  I worked on a project three years ago that had one developer and 6 other project members focused on process change, communication and messaging on new procedures.  The developer worked for about 6 months developing at probably 50% capacity, then we tested and stabilized for another 3 months or so and then it was all change management tasks.  The equivalent of 2 full-time people focused on change for over half the duration of the project.    Interestingly on this project it was changing business processes within the administration that were the focus of the change, not the target consumers of the information – in fact, very little was done beyond strategic messaging and an awareness campaign to that audience – I would like to take some credit here – from a user perspective it was usable - the language and terms used, were understood by all users.  (shameless self promotion ends).

Bunburying for project success 

Like the Importance of Being Earnest – to succeed in a project a double role or bunburying is necessary.  (stick with me folks…) the infamous Oscar Wilde invented the term Bunburying.  It is the art of inventing a friend (here our friend is Usabililty) whose troubles are so compelling that nobody will question the need to visit that friend at short notice, and for any length of time (spend time promoting the need for and execute the work on usability).   The art of Bunburying, when perfected, can enable a person (change management leader) to follow their whims [gut instincts thank you very much] without fear of backlash from meddlesome friends (project managers) and precarious family obligations (project sponsors).[3]

Usability needs change management and change management needs usability – both equally compelling neither are questioned when they appear together.    

I’ll summarize – achieving usability is a component of a change management strategy:

• user participation is key
• don’t be lured by a growing feature list 
• consider that your audience have to get on with life and don’t live for your projects 

If these concepts weigh heavily into your project planning, design and implementation decisions then you should be ok.

————–
[1]   Image source: href=”http://seattletimes.nwsource.com/news/local/seattlecenter/milestones/” mce_href=”http://seattletimes.nwsource.com/news/local/seattlecenter/milestones/”>http://seattletimes.nwsource.com/news/local/seattlecenter/milestones/
[2]   http://www.crm2day.com/news/crm/EpupEEFuAlbfuEWzQS.php
[3]   http://en.wikipedia.org/wiki/Bunburying