The Code Whisperer

I’ve seen this so many times. A design or requirements document is produced for a system and shown to a number of people. And one person doesn’t like it, so they shout loud and long. Often this someone in a senior position and who won’t use the software in any case.

The most damaging case I’ve experienced was in a meeting with a photocopier manufacturer, who wanted to expand their system to handle rental of fax machines and had employed the consultancy I worked for to carry out a feasibility study. Early on in the meeting one of the participants suddenly blurted out “we can’t do this, it’s against the business model” and went into a five minute rant and stormed out. Being slightly worried about the political implications of this event I asked what position the they held in the organisation. It turned out to be the secretary to the sales director and not someone who could determine the future direction of the company.

My point is quite straightforward. When evaluating feedback look at every comment and, initially, ignore the source so that the outwardly passionate comments don’t swap comments made by others, who may be just as passionate, but not so vocal. In the cold light of day you would value the comment of someone that uses the software every day if it conflicts with comments from someone that is a casual user, but pays your wages. In practise this is hard to do, but there is something you can do to make a decision based on quantifiable data: usability studies. A mixed group of users, different systems, a video camera and with websites a product like crazyegg will provide additional analysis. A usability study takes some setting up, for a start there needs to be two user interfaces to test, but it’s better to make a decision now that creates a superior user interface that people will use than have to either have a product that people don’t like (and will be reluctant to use) or have to release a revised UI in a short space of time.

I often see complaints in the industry press about the usability of software and websites in particular. Sometimes I think there is a bit of a battle between the extreme left and right of the brain, but as ever there are bits to be picked out of both sides. Every now and then I see a design that leaves me dumbfounded. Last week I looked at an online remembrance book for a crematorium. A leaflet from the crematorium gave the website address and the password required, plus sketchy details on how to locate it on the website.

Having arrived at the remembrance book, which was produced in Flash, often the cause of usability concerns, but not in this case, I was asked for a date. I assume the date of death, but it could be the date the entry was made into the book. Having plumped for a date I was then asked to choose from one of four volumes. I have no idea. Having given up on finding the entry I was looking for I chose to look at the first volume and was presented with a beautiful high resolution scan of the actual remembrance book pages.

Quite frankly as a useful application it fails. If you know where it is you are fine, if not you have a bit of a search in front of you. Small changes to the user interface, with large changes behind the scenes would make this much more useful. Remember this should be available to generations to come, who may be as interested in genealogy as we seem to be at the moment, so why password protect it? Maybe there’s a danger of identity cloning, but the death will be a matter of public record in any case Then have a search system working on names and dates leading to the scanned page. Seeing the scanned page is a valuable asset and I wouldn’t suggest changing it.

Without a doubt this website hasn’t had any usability input, which is a shame as it won’t be used to its full potential and possibly regarded as a failure, where with consultation early on it would have been much better.