github linkedin flickr email
User Experience: The Cardinal Rule

Recently, I installed linux on my main, desktop computer. After it booted back up into Ubuntu 10.10, I was like, “Damn, linux has come a long way in the last 5 years.” It was fast, had a good window manager, most programs I use have a native linux equivalent, and it worked out of the box.*

However, that little asterisk is the rub. My wifi cut out after 15 minutes, dual monitor support wasn’t great, DRM keeps me from streaming Netflix and playing movies I bought on iTunes. To cap it off, I had to spend close to a full day configuring programs and settings at the command line. But, for me it was actually a step up in user experience. I can quickly set up sandboxed development environments, look for problems more quickly because all my settings are in flat text files, have a full range of open source tools that can be tailored to my specific needs, and it NEVER crashes.

I realize though that most people can’t and, more importantly, don’t want to deal with these issues. They just want their computer to work. And this is why I am such a proponent of Apple. In fact, I think the user interface is so good on Macs, that I themed my Linux desktop to act like one. But, Apple takes an approach that is antithetical to the way Linux is developed.

Apple keeps the Mac universe under lock and key for a reason. By controlling the production of a computer for start to finish, they can preserve the user experience. Why do mac’s have fewer hardware compatibility problems? Because their engineers only have to worry about a few hardware combos. Why is iTunes such a seamless experience? Because they can simplify operations by designing for a small iUniverse of devices. They can guarantee that you have a machine that feels solid in front of you because there isn’t another manufacturer who is going to cheap-out on a plastic case and cruddy display. In essence they have traded flexibility for quality. For 99% of users this is a good choice.

What I see often happening (especially in the hardcore computer science world, but it is creeping into the web as it matures) is that software is clearly designed by an engineer. Engineers by their very nature are feature-hungry. They want to design software that is the epitome of flexibility. Their software is probably wickedly powerful, but makes absolutely no sense in terms of operation.

This practice was painfully obvious at my previous job where all our bank operations software was designed in house. I knew a couple of the programmers in software development and they were insanely smart. If you wanted to do some really esoteric transaction you could do it, but you probably had to click through a 15 pages of dialogs with 30 settings each (I’m not exaggerating). It had a tremendously steep learning curve that bred ineffiecency and mistakes.

Those engineers had forgotten the cardinal rule–the rule that I think makes Apple so great.

More important than the functionally of the software or device, is the ease of use by the end user. If you forget this concept you are bound to upset the very person you are trying to help. Not only did you just lose a customer, but you just defeated the very purpose of your software: to help someone.