Monday 31 August 2009

Reflections on software desing

Last week I spent lots of time tweaking the user user interface of my other project according to Cooper's principles. Interaction design is fun if you are a designer and NOT fun if you are a programmer, so it is useful in the sense that it helps you get away from the “this will take ages to implement” way of thinking. It is amazing how tempting it is to ignore what the user needs and do it your way, the way it is easy to code. Here is a simple example: to go back to the main menu, you have to click File> Back to main menu. Makes sense, doesn't it? Well, apparently not- I had three different people telling me on three different occasions that they would very much like to see a Back button on the screen at all times!!! Funny thing is, those modern GUI builders let me do this minor change it less than a minute, and I still resisted it until my boss came over and “commanded” me to do it. And this is just the tip of the iceberg- the whole program makes perfect sense to me, since I designed it and implemented it. But to anyone else, it is just an comprehensible collection of buttons. This is what Cooper calls “the dancing bear” paradox. Imagine you want to go to a dance festival. But then you see one of those dancing bear. Do you just walk past and go to a proper dancing event, or do you start giggling and watch the bear's performance? If the bear is a computer program, the average user would just walk past- yes, it is cool that it can move in such an unusual way, but this is not what I wanted in the first place! And then there is that group of enthusiasts, who will stick with the most horrible product simply because it allows them to do something new, no matter how hard it is to use. The third group consist of those who are already more or less skilled computer users, who are too used to the crappy software to simply switch to another product. This is clearly not the way things are supposed to be. Computers are tools, a means to a goal, not a limitation. The problems we all tackle on a daily are hard enough even without software getting in the way. That is why developers should resist the temptation to do it “the convenient way”, to re-use code (despite all the benefits of that) and forger the famous “If it ain't broke, don't fix it” principle.

Next time, an extension to the Cooper model of computer users.

No comments:

Post a Comment