The importance of feeling the consequences of your own work can scarcely be overestimated.
I sometimes fold laundry in our household. Well, okay, I occasionally fold laundry in our household. That is to say, at least twice I have folded laundry in our household. And on one of these occasions, my long-suffering wife asked me a seemingly random question.
- Wife:
- How do you hang hand towels?
- Me:
- What?
- Wife:
- Hand towels. Like if you’re hanging a towel on the rack, how do you do it?
- Me:
- (picking up a towel I’d just folded) The normal way, threading the narrow end through the towel holder. I’d just unfold the towel once and…oh.
Turns out I was completely incompetent at folding hand towels, because I’d been folding them in the wrong direction. Thus, anytime someone wanted to use one of the towels I’d folded, they had to first unfold it all the way and then re-fold it.
Apart from making me feel like an imbecile, this little experience reminded me of a lesson I’ve seen in action many times. Had I been the one hanging hand towels in addition to the one folding them, the problem would have been immediately obvious. But unless we actually use the end result we’re producing (or have excellent user feedback mechanisms in place), we’re flying blind.
This is especially true in the software world. If you’re not using your own software, then I’ll take long odds that it’s got significant usability problems. I have worked with developers who blame everything on the user, vindicating their own blinkered view of their software product. “gah, these users. If they’d only use the software correctly then we wouldn’t have to make these silly changes.” I cringe every time this happens, and I’ve heard variations on it more than once in my career. If you’re blaming your users for problems they find in your software, it’s time to find another career. The whole point of software development is solving people’s problems. If you’re not interested in doing that, then what are you doing here?
The need for real-world feedback on software is one of the reasons “hallway usability testing” is so valuable. The idea is that it doesn’t take a special kind of user to find usability problems in your application. You can grab just about any random human being who is not the guy who wrote the program, sit him down in front of the computer, ask him to perform a task using your software, and immediately start discovering usability problems. This kind of usability testing is embarrassingly easy to perform, and the majority of development shops (and developers) don’t do it.
The fact that this is true makes it all the more embarrassing that such vast quantities of software are so difficult to use. Take time tracking software, for instance. I have never worked for a company whose time tracking software was a pleasure to use. In all cases, it would have been easier to just enter time in an Excel spreadsheet. (Come to think of it, I believe the first company I worked for actually did track time this way.) I can think of no reason why this should be true, that all time tracking software stinks. There is nothing inherently difficult about writing software to record how much time you’ve worked. But developers, by and large, do not put a premium on software that’s eminently usable, so long as it can be made to work. “Does the software allow users to enter time and generate a report for managers? Great. Meets the requirements. Done.” In fairness, the blame does not land solely at developers’ feet; often companies are unwilling or unable to pay for the time required to really polish software. But although the law of diminishing returns is definitely in effect here, it does not take a huge investment to make some big gains in software usability.
As a developer, start by forcing yourself to use what you’re writing (and use it in unexpected or unusual ways). Also, put it in front of a disinterested party and make them use it. Watch (or record) – but don’t give them any hints. It will be painful, but it’s pain you need to feel. Take the results, pick the top three worst problems the user ran into, fix them, and do it again. Iterate.
As a user, start being willing to pay for software that’s elegant and easy to use. These attributes are admirable goals in and of themselves; we should be encouraging them to the extent we are able.