Frustration in software

Jeff Atwood’s post yesterday stroke a very sensitive chord. He claims that nobody hates software more than software developers, because they actually know what’s going on. This is probably not true for every industry, but certainly something that rings true. So who is going to protect us from incompetent software developers?

I’ve never met somebody who hasn’t had issues with software (even Mac users, yes :P).
As Scott Berkun so aptly states:

If you look deeper, you’ll find that when people say “this sucks” they mean one or more of the following:
* This doesn’t do what I need
* I can’t figure out how to do what I need
* This is unnecessarily frustrating and complex
* This breaks all the time
* It’s so ugly I want to vomit just so I have something prettier to look at
* It doesn’t map to my understanding of the universe
* I’m thinking about the tool, instead of my work

Unfortunately, people who create something are also very sensitive about it (well, yes, I did recently get my teaching evaluations, why do you ask?). This is the part where it’s sometimes more useful to let anybody but the creator do the user-testing. When testers can only express their frustration through “This sucks” and “I hate the way it works” it can be very helpful to have a translator at hand. So, contact your friendly user-experience expert and ask them to help you out here, because apparently the feedback is so bad that all you can do is become defensive.
While this isn’t really the reason I started in Human-Computer Interaction, I do have to say it’s one of the more challenging and satisfying aspects of the ‘job’.

 

The inmates are running the asylum

Or why is usability and user experience so important for softwere developers and engineers, and how do you convince them it’s so bloody important?

The inmates are running the asylum, by Alan Cooper

This reads like a business-book, which is what it aims at. It does give a good feeling for what’s important when you develop software for people that aren’t you, especially when it comes to working through specifications (no matter who the specs are given by). Features of your software are not what is important, rather that users are able to reach their goal. So one should work goal-oriented and put in features that help users reach their goal, not put in features just because somebody thinks it’s interesting (think pointy-haired boss).

Engineering methods don’t work to solve engineering problems, because you’re blind to your own problems. A different method will probably work better. Also, it’s difficult to do both back-end and front-end design so separate both but they still have to work together. There is a conflict of interest between what the programmer wants, and what the user wants. So you don’t let a programmer referee whether a program is doing what the user wants (unless it’s something she designed for herself to use, obviously).

Bribery can work to find out what programmers are doing, but you shouldn’t have to resolve to it. On the other hand, maybe you can train some sense into them that way. Or present it together with a rational, defensible reason. In terms an engineer can understand.

Bottom line: you can listen to your users, but it’s even better to observe them. If you only listen, you’ll end up trying to sell them a 12-headed dragon.