About a year ago at a conference, a programmer came up to me for some advice about an unfortunate user interface he’d built. It was a pretty miserable affair: a combination of displaying too much information and offering too many choices, while at the same time burying the one thing that the user actually wanted to work with. It was full of classic UX – user experience – mistakes and usability problem, and I suggested the usual suspects: go back to user stories, develop some use cases, try to figure out what the users actually need.

That did not go over well. I’d assumed that the programmer was still working on gathering feedback, since he was asking me to look over his design. So I was surprised when he mentioned that it would be difficult to make changes to it, because it had already been rolled out and his users were using it.

That’s when I decided that this was a devious supervillian who secretly hated his users. Or, possibly, just a thoughtless jerk—I couldn’t really decide for certain without seeing his secret lair. (Hint: If he has a secret lair, it’s probably the former.)

My point is that if he did hate his users, then inflicting bad UX on them was a perfect way to make them really miserable.

You can’t just add usability at the end of the project

You’d be surprised at how often programmers are completely unaware that they have serious UX and usability problems. Just a few days ago, someone told me, “Our users are using our software, so we don’t have any usability issues!”

One of my favorite sayings is that there are only a few ways to do something right, but a million ways to do it wrong. Usability is no exception. And one problem with user experience and usability is that it’s not always easy to diagnose UX problems in software that you wrote. Good UX is designed in from the beginning; bad UX can show up at any point along your project.

That’s why an approach that I like for fixing usability problems is to concentrate on the team, not just the software. Here are a few quick questions to ask yourself. If any of these situations sound familiar, you might have usability problems:

• A user is explaining what he needs you to build. Halfway through a sentence, you stop him and say, “That’s great! I know exactly what you need.”
• The first thing you did on your new project was start up the form or page designer in an IDE and drag controls onto a window—before talking to any of the users.
• You’ve gotten halfway thorough a project without knowing the name of anyone outside of the programming team who’s going to use the software.
• When you deliver the first version of the software for users to test, it’s the first time they’ve seen the GUI.
• You find out that there’s an entire feature that your users aren’t using… or a feature they don’t even know about.

If any of that sounds familiar—or, even worse, if you’re now pissed off at me because you don’t see what’s wrong with any of those scenarios—then you should definitely consider getting some UX help right now. (I’d offer to help you myself, but I’ve got my hands full with my own projects!)

One of these days I’m going to start an organization called PeTU: Programmers for the Ethical Treatment of Users. We’ll set up a protest outside the office of any development team that inflicts bad usability on their unsuspecting users. For the sake of all our sanity, please stop inflicting bad UI on unsuspecting users! If you don’t, I’ll have to stage an outlandish, somewhat juvenile protest outside your office.