systematicHR

The intersection between HR strategy and HR technology

systematicHR Avatar

I’ve been trying to sell people on the Google Android operating system for smart phones lately.  I’m not sure that it’s really about the Android versus the iPhone for me – more likely it’s the fact that I’m a long time Verizon user and won’t leave – since Apple is not currently available to me, I get the Android.  However, the user and market perceptions of the iPhone versus Android seem to be a significant difference in philosophy.  This is odd since both companies are basically known for ease of use (each in its own way).  Google is well known for the “single field search engine page finds all”, and Apple is well known for the “single dial does all” iPod.  But in the world of phones, Apple still caters to usability, and Google seems to cater to people who want more advanced ability to customize their environment.  Either way, until this latest departure, both organizations seemed content to treat all of their end users as idiots – and it worked.  They were able to bundle incredible functionality in a single element.

I recently had the pleasure of sitting in on demos of core HR platforms, a variety of talent management and learning systems.  It occurred to me that each category of software seemed to have varying differences of usability between their different types.  While my thinking is in no way complete since I have not actually seen that many vendors of late, I’m wondering if indeed there might be something to the following usability argument.

Core HR platforms have in general  catered to just the HR user community.  In effect, these are generally specialists and power users of HR systems.  Next in line, talent management systems rolled out HR technology to employee and manager populations, but most of the major interactions in the first couple of waves of TM were manager based.  These technologies really stewarded managers through employee, compensation and succession review processes.  Lastly, learning systems seem to be the most employee focused.  Managers have proportionally less interaction (compared to TM) while employees actively look up courses, participate in learning, and manage their transcripts.

My theory is that learning systems will tend to evolve the fastest when it comes to highly usable systems (again, assuming that legacy systems can adapt quickly, or newer platforms will already be there).  Basically, the more end users you have, the less room for error you have when it comes to creating simple transactions.  Lets say for learning, you have at least 5 times as many end users as with most core talent processes.  (I realize that many of you will want to tell me that employees participate in reviews and talent profiles, but come on, I think we can all admit that most TM processes are really focused on the manager in today’s world).  Similarly, core HR has about 20 times fewer users than TM and 100 times fewer users than learning.

Basically, what I’m saying is that we all complain about the usability of some systems.  Some vendors are burdened by legacy technology that they simply can’t get out of.  but other vendors who seem to be more capable of advancing usability have not.  My theory is that when we talk about core HR, vendors simply have not had to make systems significantly more usable.

systematicHR Avatar

2 responses to “The Lowest Common Denominator”

  1. […] This post was mentioned on Twitter by Starr Tincup and Wes Wu. Wes Wu said: The Lowest Common Denominator: I’ve been trying to sell people on the Google Android operating system for smart … http://bit.ly/eXA8Jo […]

  2. Andrew Marritt Avatar

    “My theory is that when we talk about core HR, vendors simply have not had to make systems significantly more usable.”

    You’re spot on with this. Usability is a huge issue with many HR systems, mainly (my theory goes) because there hasn’t been any real commercial pressures to fix it.

    I’ve conducted usability tests, even to the level of eye-tracking, on multiple HR systems. Our view at the moment is that whilst most technology is relatively mature, a key reason for the success or failure of implementations is usability in it’s broadest sense. With systems that are part of someone’s job and they use it every day they learn work-arounds. When they are rolled out to a broader user pool who has more infrequent use then they try and find ways to avoid the system.

    An example is self-service. I’ve lost count of the number of times I’ve seen instances where employees can’t fathom the system so quickly give up and call their HR manager. For recruitment systems candidates just give up.

    Vendors of course make money from post-implementation customizations needed to fix issues so their motivation to address the issue is low. Client teams often compound issues with clumsy changes during implementation.

    Here’s what clients should be doing (IMHO)

    1) Build usability as a key part of the selection process. Test shortlisted systems and ensure that changes are costed in advance.
    2) Test throughout the design phase. Lo-fi testing is usually OK.
    3) Build-in ways of regularly capturing experience-based information on an ongoing basis.

    Testing should always be done with target users, not the project team.

    Most of the tests I’ve conducted have shown basic usability issues. Some can be customised by the user, others (like search functions that don’t work) are far more fundamental.

    There is nothing mystical about getting good usabilty. It’s just a matter of working with real users and being rigorous in the way you prototype, test and re-test. The additional costs and time taken with this approach are tiny compared to the implications of getting it wrong.