Thursday, 9 June 2011

The 4 most common UI mistakes

Design being a reflection of the data function rather than user goal oriented

I mentioned this is a previous blog, but my example was perhaps a little too far from home for most people so I will give an example of a Microsoft Excel behaviour that has been generating support calls for a very long time, and I truly do not know why it has not been changed.

For as long as I can remember when entering a purely numeric value with leading zeros into Excel the zeros the column type automatically changes to number and the zeros are removed.

Now I am assuming that if the column type is number then the values in the column can be stored more efficiently (as integers represented by bits rather than a strong) and that math calculations can be performed more efficiently and accurately. If this is the case then the turning into numbers has a potential data function benefit, but for the end user it is almost always conflicting with their goal.  Typing in a phone number or a barcode, which are surely the most common cases of leading zero numbers, will simply lead to data loss and frustration.  The user is forced to learn about column types and re-import their data.

Lack of end user empathy

Well this topic heading could encompass any of these types of failures, but I want to focus on the lack of contextualising the users situation when they are using this software.  You might hear a software developer saying "that is not the way the software is meant to be used".

A long time ago I worked as a first line support technician at a high volume call centre.  The development team created a new application for call logging.  Now the application would only allow one person to update a call at the same time, but multiple people could read from it.  In the instance when first line support were unable to resolve a case within a set time frame we had to pass the case through to second line support.  Now what the application developers thought was that all notes should be completed by the first line team before the second line team received the call, but what initially happened was that the first line support would continue editing the case while they were passing the case over and save the data at some point after the second line technician opened the case.  The second line technician would then edit the case and then on saving would lose all of their data because of the intervening update and have to type it all out again.

This system reduced efficiency noticeably, because first line technicians would have the customer on hold for longer as they corrected their notes, the second line technicians would generally type their notes on another application before copying their notes into the call logging application and it was essentially a pain to manage as a user.  Specifically though by the head of software development we were told we were to type up all notes and "launch" the call to the other person before they opened it.  This application design certainly lacked empathy with the role of the user that it was aimed at.  It is a shame that so often software is written by people that never have to use it...perhaps this would help empathy in software design?

Warnings rather than guidance

Too often applications have dire warnings of potential data loss and that misuse can seriously damage the data integrity / application.  Really this is a poor crutch, your application should do the best to avoid ever needing these warnings.  Google's Gmail undo when deleting email is a great example of this, no are you sure you really wanted to delete that ok button extra, just accept the users action as their intention, but have a failsafe should it have been an accidental action.

Designing for the 0.0001% case to the deteriment of the 99.999% case

Too often I see features which initially sounded great, but then fall a part because they are too complicated to use because they focus on the needs of one extremely technically competent individual with extremely specialist requirements.

Not making bold decisions and instead creating options

Yes it can be frustrating not having the ability for an application to perform a task in exactly the right way, but in many ways it is also equally frustrating not being able to work in the most common way because you have to search through a myriad of options.

There are many techniques for getting around this problem:

1. Create defaults as you go.  Essentially this is recording customer action and trying to learn the best set of options. This does have its draw backs, but can help a complex application be setup quickly and teach the user as to the available options

2. Assume the "best" defaults and educate how to change them afterwards.  Sort of the opposite of point one.  IE9 recently exhibited this kind of behaviour in respect to IE plugins.  It installs them and runs happily a long, but if one of them is taking a long time to process it suggests the option of disabling it.  Allows you to work as you want, but then educates you as to the options and continues on.

3. Deep thinking to the problem - if a solution does not seem elegent then you have not given it enough thought.  Spread the problem around the company, friends and family can even contribute.  They may not give you the answer, but even the smallest spark can move you towards a much more elegant solution.

4. Perhaps there is not a solution right now....Strong decision making to not introduce unnecessary complexity is important. Apple proves it is possible to sell very locked down products that "just work", they follow a number of the techniques above, but they are one of the few companies strong enough to say "no you cant do that".  Sometimes you need to say no that will not work it is only beneficial to a tiny minority and detrimental to everyone else, of course even Apple is sometimes wrong...

No comments: