There has been so much publicity around e-readers and the Apple iPad lately. In truth, I’m totally captivated by both of these technologies, but have not jumped in the market yet. The iPad seems wonderful since it is basically the next evolution of the net book, or mini-laptop. It has a great user interface, is generally lighter than a net book, but combines some of the functions from the iPhone device, letting you take emails, calendaring, video, applications, and yes – an e-reader with you. The problem with the Apple device is that the e-reader is in full color, not in what is called “e-ink.” E-ink is attractive because it allows you to read a page virtually anywhere. It’s visible in full sunlight. Unfortunately with the e-readers that use e-ink, the technology seems to “flicker” every time you turn a page. I’m not sure what the nuance is behind the technology, but a 1 second screen flicker on page turns is rather annoying. Considering that you would turn a page an average of 400 times a book, and every 30 seconds, this can be quite upsetting.
Sometimes, it’s the little things that bother us, because while they are little things, if they happen all the time, the accumulated disturbance is rather large in scale. As we go to SaaS software environments, but even in our legacy on-premise systems, almost all end users have become accustomed to waiting for screen refreshes. I actually remember back to the late 1990’s when one application hosting provider actually issued a SLA that the screen refresh would be no more than 3 seconds. Imagine the downtime accrued over the course of a year if a hands-on application user lost 3 seconds every time she changed a screen!
Even in today’s speedy technology environments, we are often subjected to screen refreshes that take a few seconds. Sometimes it’s our own internal corporate networks, sometimes it’s the internet, but sometimes it’s the servers as wel. In HR, we tend to pull large amounts of data – employees have multiple roes of data on multiple data elements. There’s a lot of data chugging gowing on in that back end.
Imagine if Amazon.com or Google acted the same way. We would probably never use those systems, and they would have died a fast death in their infancy rather than becoming the behemoths they are now. Amazon literally pulls together a page on the spot – that page does not exist before you request it, rather it’s just a set of disparate components that come together at the point of the user request. Same thing goes for google, it takes your search request and pushes it through an algorythm, then searches the entire internet to return results. On systematicHR (admittedly a slow running site, I don’t pay for a fast host), when you request a page the server responds to 88 queries and returns results in 0.57 seconds on average. And that’s slow in internet speed.
Since converting most or all of our HR applications to we based apps or services, why is it that we still accept much of our technology running on legacy speed instead of internet speed? If we were end users with a choice, we would have made other choices and abandoned anything that delayed us from doing our work. Most of us hate waiting, and certainly the best performers hate it. When it comes to employee and manager self service, employees might be more willing to wait, but they are probably also waiting for dinner to finish baking in the oven while they wait for the screen to confirm their phone number change. As an employee though, I myself have been known to abandon at the first 404 error screen. Managers on the other hand, certainly have better things to be doing than waiting for slow screens, and the accumulation of individually insignificant annoyances leads to large amounts of displeasure with HR.
Similar to the iPad or e-readers that provide great functionality and targetted types of usability, little things that go wrong (not being able to read the iPad in sunlight, or having e-ing screen flicker) can be pretty annoying. As users, we can usually manage small annoyances, but we’re not good with problems that happen all the time and don’t get fixed. Our image of HR is often through the user experience of our applications that we roll out. As we increase our footprint of HR technologies in SaaS, speeds should gradually increase, and we should also be looking at SLA’s to ensure that our end users are getting optimal experiences.
One response to “Screen Flicker and End User Annoyances”
Dubs
You’re spot on with this yet it is something that can be managed easily. Our take on this is that, with technologies increasingly mature, it is the usability and experience of the technology that determines success (users happily using the system) or failure (damaged reputation, users finding work-arounds).
There are two key reasons for this failure: design issues in the systems (and many big HR technology providers are poor in vanilla state) and issues brought about by clumsy customisation.
I rarely see a system selection which included user experience criteria in the selection criteria. Usability testing the shortlist is simple and provides points that can be discussed as part of the negotiations (as changes later will inevitably cost more!).
Of course you need to really understand what the users want to achieve and their expectations. Deep behavioural insight is a key part here.
It was my belief in employee experience management as an emerging topic that persuaded me to launch OrganizationView earlier this year, bringing together a team with consumer research and experience backgrounds. Technology is only one part, albeit a very important one, of a carefully planned and understood multi-channel employee experience.