Everyone has seen them – every developer has fallen in at some point – the common pit-falls that are usability no-no’s. But how they are perceived varies. Developers with enough time under their belt will be at least partially blind to them – for some reason, active development will make you unable to judge usability unless you educate yourself.
This may sound a bit harsh – but it is actually true. When you know at least part of what is probably going on under the hood – you take a lot of things for granted. Of course that functionality is in the menu under Tools -> Settings – that’s the garbage can for any developer… but of course you should just right-click, hold control and drag it across the screen waiting two-thirds of a second for Windows to update the UI before moving out of the listbox.
And the things that annoy developers are unlikely to be the things that annoy Joe the Plumber and vice versa. Developers will complain – “But I have 47 controls – and if I don’t use up three rows in the tool-panel, the user will never see my brilliant functionality and I’ll spend hours explaining how to reach them”.
So, what to do? It’s actually quite simple, start looking at things that you don’t remember using – without looking, tell me how you activate the rear-view wind-shield viper? Most cannot. They will still be able to do it, when they sit in the car, but they will be unable to tell you. It is a combination of placement and icons incl. mapping. Cars must meet certain usability demands for drivers not to endanger themselves and everyone else on the road. All critical functions must be doable without taking your eyes of the road.
So, what does the car manufacturers do better than your average software developer? They spend a lot of time and energy on making sure buttons are where people expect them to be, make them of varying size and texture to allow the driver to find them without looking. And they place all the controls you need the most (steering wheel, gear stick, the horn and light-controls) at the most convenient positions. The less-used controls are not hidden away, but placed in secondary positions and less convenient to avoid taking the focus from the critical ones. (And of course, the car stereo designer still has not learned anything – I count 34 buttons on mine – 33 of them identical in size, colour and texture with tiny icons with made-up acronyms on them).
And they don’t start switching the brake-pedal with the accelerator, because it just seemed more aesthetically pleasing! Nor do they start making the car turn right when you turn the steering wheel counter-clockwise. (So, for goodness sake, stop placing the cancel-button to the left of the ok-button) In other words – they follow conventions even if it might conflict with other goals.
To sum up – to make better UI-designs – stop trying to invent the new and better wheel – and rely on already established conventions and use the hard-earned lessons other people have learned before you.
I recently started re-aligning my preferences when coding. Up until now, I’ve been focused on learning the technology and reaching a competent level of understanding why the technology works the way it does. Also, I wanted to write better code. I’m in no way among the most competent in these areas, but it is mostly a matter of using my new-found capabilities rather than gaining theoretical knowledge. So, I need new reading-material – and I started throwing myself at “The design of everyday things” and “Universal Principles of Design“.
I’ve always had a pet-peeve with badly designed software, but being unable to express what was actually wrong with it – I realized I had no vocabulary in usability. So, I started with these two books that are recognized as must-reads for designers generally. What I learned was not so much how to design beautifully nor how to design in the first place, but rather a vocabulary to express what I already knew and also, some research to back up my understanding of why design is important. These two books are not aimed at software designers in particular but rather the principles behind design in general. As such, many of the principles don’t really apply to software.
Most developers face a challenge when confronted with the word usability. They all know it exist, but most do not see the problems because having a technical insight makes you blind to the problems non-technical users have with their creations. Concerns are discarded just because the developer a) does not see the problem and b) cannot relate to the underlying cause.
The catch-phrase from my reading has been: “The user must see the conceptual model to understand the interface”. For us software developers, this means that if we are unable to convey the conceptual model of what we wish to accomplish in the GUI, the user will most likely fail. The conceptual model is basically “what happens under the hood” – in other words, it is everything the user cannot see. Humans are adaptable beings and jump to conclusions. This is why we have users saying “the computer freezes everytime I turn on the coffee-machine, so, since I started drinking tea, it has been running fine”. We (the IT-people) know this simply cannot be the under-lying cause, but the user does not know the technical bits – he saw to circumstances happen at the same time, and concluded that they must be intertwined.
So, what to do? Should we start educating users to be IT-minded – maybe throw in a MCP to make the users understand why stuff works the way it works? It would certainly make Microsoft happy… but no, it is not a viable solution. Instead, we need to focus on making better GUI. We need to make the conceptual model clearer and simpler. When the application fails, the error-message should not read: “Exception occured in major module hj_uuullk. Fatal failure reading harddrive kl_llij at position 0xE3F2E5″. It should read: “There was a problem with opening your document – you did nothing wrong. Technical staff has been informed about the problem and will fix it as soon as possible. If you want to follow progress: >link<. Please, do not attempt to open this particular document before technical staff gives the go-ahead. Other documents should work fine. If you need the document before, contact jim@farkvad.com.”. The user gains no insight from the first error message. Basically, he has no way of knowing if he did something wrong or it was a software mishap. All he knows that something went wrong, but he is left thinking… “Maybe my coffee cup was too close to the screen… hmm… could be that it was due to reading an e-mail at the same time…” The chances of him reaching the correct conclusion is slim-to-none.
The wife has kindly updated my wordpress installation and restored my old theme for your viewing pleasure.
I will return shortly with a series of posts around usability and general design concerns.