Usability and Process Control

A blog post by James Christie ( has prompted me to post a few thoughts about recent experiences I have had where illogical (at least to the user) processes have apparently gone unchallenged.

The Utility Company

I received a letter one morning from my electricity and gas supplier to express their sorrow that I was leaving them – but I was not intending to leave them at all!  I contacted the company and explained the situation.  The operator looked up my account details and said that there was no record of me leaving them.

A couple of months later I attempted to log on to my online account management system but I was unable to do so because I no longer had an account with the company.  I contacted the helpdesk again and was told that another utility company was supplying my electricity (not my gas – that was still with them).

What followed was a lengthy process to get my account reinstated.  I became very interested in establishing what went wrong when the same thing happened a second time.  This is what I found out:

  • A representative of another company had mistyped the meter number of a property.
  • At no point was a check carried out to make sure the installation and billing addresses matched.
  • My energy company had no means of verifying that the details matched because insufficient information was sent to enable them to do so.
  • Energy companies are reliant on people noticing that they have been erroneously transferred and informing them.
  • Having erroneously transferred my account to another supplier it was impossible for my original dual fuel account number and information to be reinstated because only the one fuel type had been switched.  This is despite a regulatory requirement for them to do so.

I would be very interested to hear which testing techniques were employed by the suppliers and which test types they used.  I suspect there were a lot of automation and manual scripts with very little in the way of exploratory testing carried out.

To me this emphasises the importance of elements of process auditing to testing.  As an ISO 9001 auditor I have to examine the business processes my employers have in place.  Testers need to think about the wider processes of which the software they are testing is just a part.

The Mobile Phone Company

I have experienced the opposite effect to James with my present mobile phone operator.  Far from being able to have an account with multiple telephone numbers and/or services, I have to set up a separate on-line account for each number/service.

Worse still the website for the company concerned is only fully functional in Internet Explorer.  There is a help forum which does not work at all in Firefox; one of the most commonly used web browsers.

Registering numbers/services on your account involves:

  • Entering your details on the website
  • Submitting the form
  • Waiting for a text message to come through to the telephone
  • Entering the code into the website – whilst hoping the session and/or code has not timed out in the meantime.

Once this has been done, the number/service can be administered online.

The other day my father purchased a new telephone from this company and tried to go through the registration process.  He was unfamiliar with the handset and is not adept at text messaging.  This meant he found the whole process time-consuming and frustrating and in the end called on me for assistance.

I can understand that the company wants to make sure the telephone really does belong to the account holder but there must be better ways of achieving the same effect.  Also, does it really matter that much to them?

I am sure this whole process works as designed – it sounds like a wonderfully technical solution to the desire to have users register their telephones but, again, a bit of process auditing logic could have been applied to say “this is giving a bad user experience”.

Tags: , ,

3 Responses to “Usability and Process Control”

  1. James Christie Says:

    Thanks for the mention.

    I suspect you’re right that there was an over-reliance on test scripts, rather than exploratory testing. This ties in with what I recently wrote in my blog on usability and security,

    Testers too often are thinking about seeing whether the application will do what it’s meant to do, and don’t try to see what happens if they do something they shouldn’t, e.g. what happens if they enter the wrong account number?

    When I was working with insurance management information applications I had a long argument once with a development project manager about check digits. In my experience they were typically alpha characters rather than integers, in spite of the name.

    They were stuck on the end of a numeric key, the value being generated by the integers in the key . The point was that if you miskeyed one of the integers the application could detect that the alpha check character was inconsistent with the numeric key and the account number was therefore invalid, and could flag up that there had been a miskey. This reduced the risk of people entering a valid, but wrong, account number by mistake.

    The project manager was adamant that check digits were an obsolete hangover from the days of batch processing, with input being done by squads of data prep operators. He argued that with modern on-line applications the user could see what account they were working on.

    My argument was that a close examination of the data in the applications without check digits for key fields showed his argument was false. They were riddled with input errors, with the users not noticing they were sometimes working on the wrong accounts.

    The project manager got his way, and his applications continued to churn out crud for the management information apps.

    I don’t think there’s any good excuse for building apps that allow users to inadvertently transfer the wrong account. It’s part laziness, part ignorance and partly a reluctance to stand up for professional standards in the face of schedule pressure.

    Your comment that the application doesn’t allow the company to comply with its legal obligations reminds me of the way that Tom Gilb bangs on about stakeholders and requirements. Often (usually?) missing key requirements are the result of key stakeholders not being identified. In this case the regulatory obligation was a key external stakeholder that was missed.

    Finally, building sites that don’t work properly with anything but IE is amateurish. 10 years ago companies might have argued that they were just being brutally pragmatic in recognising Microsoft’s dominance of the browser market. Now they just look plain daft.

  2. Tweets that mention Usability and Process Control « Stephen Hill's Blog -- Says:

    […] This post was mentioned on Twitter by James_christie, Stephen Hill. Stephen Hill said: Inspired by a post by @james_christie on poor usability and testing I have written the first post in my new blog: […]

  3. Kathryn Richards Says:

    I hate being an end user of a system that fundamentally does not work for the end user. A recent example was in I was trying to book flights and a hotel and due to the layout of the site, the navigation to months past july was hidden behind another piece of content. This meant I got really fed up and have completely given up with the whole concept.

    I wonder how many sites opay attention to issues like this as it must affect their bottom link

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: