Usability – where to start
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.