usability – ASYM APS – IT Quality and Safety

I came across this on a web site today:

I think among the reasons [insert product name] works so well is that it was developed not by endless betas and adding too many features requested by wankers who do nothing but play on their computers, but instead by people who understand the importance of simplicity and usability.
[Insert product name] has exactly what I need in a simple enough form that I can figure it out.

The product in question is Apple’s Aperture, but that’s not important. But Ken Rockwell (who wrote this) “even dream in Photoshop”. It’s a big statement.
This is about shifting focus to from technology to product value. Looking at myself in the mirror, I hope I won’t see a “wanker” who makes computer systems just for the fun of playing with technology. But I know the feeling. After all, it was the passion for technology that started my computer career almost 30 years ago. In that respect, I hope I’ve grown up a bit! 😉

Usability testing is different

Usability testing is done for roughly the same reason as other kinds of testing: To discover new knowledge about the system under test. In this case knowledge about how users work with the system.
But Usability Testing is a very different discipline from ordinary system testing.
In my opinion, the one thing that makes usability testing different from system testing is, that it never discovers absolute facts about the system.
Instead, a usability test will only say something about how the system works in relation to someone – and this someone is a person – or persons. And as you have probably experienced several times in your life, real persons aren’t absolute, predictable, or static – they’re quite dynamic and you never really know what to expect. Usability testing is a bit like integration testing against a remote system, which keeps changing, even while you test it!
Another aspect is that it’s much more important, yet also more difficult, to describe the context in which the system is to be used and the test is executed in.
I’ll illustrate that with a basic example: Many corporations implement systems for internal use which are not really user friendly, but since the employees get paid for using them, they don’t mind this – and once they’ve used the system for a few weeks, the system may have become an efficient work tool. An opposite example is most computer games, which are deliberately designed to be inefficient, but are usually easy to learn and use. These two systems or applications may be used on the same day by the same person, but in different situations, of course.
Setting the context is not always possible, though. For example is that most people will only respond to things which they understand: Chances are that if you had tested Facebook on users in 1995, they wouldn’t like it at all because they would not understand what it was to be useful for.
Essentially, I feel that the tester must be much more conscious about what he is doing and how it is affeting the test results. I actually believe that the description of the context itself and the way you describe it is as influential on the results you get, as the system and the users themselves.
Yes, testing usability can be very challenging!