Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, September 18, 2005

Why User Errors Are Your Fault

It's just another day at the office. Joe User has accidentally erased his work again using your software. As he curses your name for the third time this week, you rest comfortably in the knowledge that your software works as designed.

Of course, the fact that he's just one of dozens of your users who made an offensive remark about your anatomy this week might give you pause. Complaints are a bit like New York City rats (pardon the metaphor) - for every one you see, there are 10 more lurking about that you don't see.

"But wait!", you say, "The software is working perfectly, it's the stupid users that keep losing their work by hitting the erase key."

This is a too common story in the world of software. As developers, we strive to create software that we think meets our users needs, is easy to use, and gets the job done. But the users keep finding ways to hurt themselves. The temptation is strong to blame the users, but when you notice a trend in "misuse", there's no better place to point the finger than at yourself.

When multiple users keep having the same kind of accident using your software, there's a good chance that you have a design problem. Resisting the urge to ignore this valuable input can help you improve your product. Think of it as just in time usability research (although certainly it might be better and cheaper to do this up front).

So the next time you hear a user complain about a perfectly working feature in your software, listen closely, you might learn something that will help you improve your design. And the next words you hear might be rave reviews.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • This is a variation of what I call the "it works for me" syndrome, usually seen with college grads who have just had four or five years of programming assignments. Short for "it works for me, so if it doesn't work for you that's not my problem. I think that changing this perspective requires experience, usually hard-knocks experience because doing more than "it works for me" requires exponentially more effort and understanding.

    By Blogger Bruce Eckel, at 11:14 AM  

Post a Comment

<< Home