3 Rules

There are 3 basic rules to software programming. Most people don’t know them. Or if they do, they probably don’t know how to properly articulate them. So I’m going to spell out the 3 rules for you. This was talked about a lot at my last job early on when dealing with problems and support issues. Just about everything came back to one of these 3 rules, and unfortunately, rule 3 was more popular than even we believed.

Rule 1: Computers are too hard to use.

Sounds simple, but its still true. I’m in my early 30s and there are a lot of programmers that are younger than me that don’t understand this. They’ve always been around computers so it makes sense to them. Now, put that same computer that you have been flying around on in front of your parents or grandparents. Suddenly, computers are hard to use. This isn’t as big of a problem as it was 5 or 10 years ago. But it is still very much a problem. Especially when you are doing something that no one else has done before.

Rule 2: The internet is too hard to use.

The web changes at the blink of an eye and for the average user, this can be a scary thing. Imagine a site that you have been using for a year or two. You know where everything is, its clearly laid out, and its comfortable like an old pair of jeans. Now, imagine you log into your computer and now it has been updated with the latest web 2.0 technologies. All of a sudden, you have to relearn everything on the site. Hopefully, they’ve done a good job and everything flows the way that it should and the users don’t revolt. Intuitive design is not something that comes naturally to all developers. For some sure, but for many they think about completing the tasks that they were assigned and it works for them because they developed it. A/B testing, User Acceptance Testing, all foreign concepts to this type of programmer.

Rule 3: People are stupid.

Wow, I could go on this one for a while. But unfortunately, there are certain users no matter how good your design is, how good the on screen help is, and how good the training / manual is, they will find a way to be confused or break your application. Every day, the world is creating a better idiot.

Here’s one of my favorite examples:
aol report spam button

At my last job with our hosted email product, we allowed users to forward their mail to an outside account. Many of which forwarded to their AOL accounts. Normally this wouldn’t be a huge deal except that many AOL users take the “report spam” button and the “delete” button to be the same thing and are located way too close together. To the end user, it does the same thing. The message goes away. But to system administrators, this gets your servers blocked when the “report spam” link is used. Could this be too many people mis-clicking? Could this be people not reading? Could this be people being stupid? The answer may be all of the above. But eventually, it comes down to, no matter how clearly the button is marked, how clearly it is laid out. People will still surprise you with how stupid they can be.

Yes, it sounds mean and I’m not going to say that I haven’t done something stupid on a computer. I have, I can admit that. But even I can admit that I was stupid after I realized that I had done. It happens to the best of us. At the end of the day, it all comes back to the developer/designer though. You failed to make your application intuitive and when someone does something that you weren’t expecting, you didn’t fail in a graceful way that got the user back on track.

Call to Action!

So what can we do as programmers and designers? Well, remember that the internet is a wonderful place and that 80% of your users will never have an issue. Its the 20% that makes it hard and we will constantly be working to make the internet a better place.

I follow this simple rule when programming: How would my dad use this application? He falls into rule #1 and rule #2 due to his age and his former career. He’s a retired elementary gym teacher so he didn’t have to use a computer all that often. He uses one now at home quite often and does well, but he’s still intimidated about messing something up. So if I can put in graceful failures, useful dialogs and whatever other help I can give him along the way, this helps make my applications as usable as possible.