Recently I had to undertake that wonderful annual task of renewing my car insurance. I did the comparison-website bit, phoned a couple of brokers, and of course went directly to a number of insurers’ own websites to see if they could beat the comparison sites.
What shocked me was not the very range of prices offered for the same cover, but the performance of the respective websites, some of which had obviously been designed with fibre and cable broadband speeds in mind, rather than the copper that still provides the majority of access. One site I actually gave up on, because it would probably have been quicker to drive to my local insurance broker and have a chat!
The serious issue here is that not everyone is in the office using a PC, with a high speed internet connection, and we shouldn’t design our processes or select our systems around that scenario.
The expectations of all users in terms of performance and response across the internet are getting higher. You only have to see the faces of smartphone or tablet-using commuters on a train when it moves from an LTE/4G area to 3G. Whilst many cities now have good fibre to premises, and increasingly high-speed publicly-available WiFi, you do not have to travel too far outside to find that these are not available to physical premises, or mobile users.
I have a friend who works in rural England, with a respectable 7MBPs broadband connection over copper, which he uses successfully for daytime work. That is until about 4pm in the evening, when the children in the village get home and fire up their consoles, which drops my friend’s experience to less than 1 MBPs, making his Skype calls with the West Coast USA a bit wobbly. He has been told by his broadband provider that because the number of business subscribers in his locality is relatively low, it will be many years before his exchange will be upgraded to fibre. And of course for the same reason, no other provider is interested in competing with the incumbent. His location also puts him 1km too far for LTE/4G coverage, and even his 3G suffers capacity problems.
Whilst that is a single example, unfortunately it is going to be the reality for many years to come for the increasing number of business people who are not permanently in the office.
Many enterprise applications, and even ITSM support tools, now have an app for tablets or smartphones, which reduces the amount of clutter that appears in the desktop versions, and often simplifies the process used. However, to my pain I have found that these are often just “webified” variants of the desktop version, and many still retain references to the server during the process. As with my car insurance story, this will often result in delays in response time, and sometimes, because timeouts are built into the application, this could cause the process to fail. Even some of the most popular cloud-based enterprise applications (advised not to name them – but you know who they are) were not originally designed for BYOD and mobile use, and suffer the same issues.
Apps and web interfaces for applications that will be used where broadband access may be variable and across a range of devices, need to have really lite interfaces and be tolerant of variable bandwidths that may (or may not) be available.
This is a challenge for both internal developers and the persons selecting the enterprise systems that support the business. Of course the biggest challenge is for the vendors who need to migrate their enterprise systems into a solution accessible across variable bandwidths.
The real test of great IT support for access to your organisation’s systems is not within the office, 9-5 Monday to Friday, with 100MBPs Ethernet, WiFi and a 26” screen, but at 3:00am on a Sunday morning, in a cold airport waiting area with just 3G mobile coverage and a smartphone. If you can deliver good service to the beleaguered road warrior who has missed their flight, then the people in the office should feel very spoilt.
So tell me, are you designing and testing around the REAL user/customer experience?