Programmers don’t like users. In an ideal world, whatever product they are designing would be beautifully written with the latest trendy technology, passed on to a testing department (preferably in a different city), and never sold to a single user. It would work like a charm when configured correctly through hacking various text and script files in Notepad, produce in depth exception reports for every problem encountered, and have a beautifully crafted and fully modular framework of code that can be reused in every future conceivable product - whether a flight simulator for NASA or a stock inventory for Jerry’s Fish and Chip Shop.

The problem with users is that they tend to get this crazy idea that what they see on the screen actually is the product. They seem to think that the hastily thrown together heap of grey dialogs and tacky icons sourced from a free download site is what they’ve paid all that money for.

They’d be right.

Software is designed to be used, which means it’s designed for users to use. Note the emphasis on the word use here. When someone pays you money for a piece of software, they don’t care how the underlying code base has been constructed, and they don’t care about the structure of the database. All that matters is: Can I use it to do the job, or will it cause me grief?

Every programmer pays lip service these days to the importance of user interfaces, but in most cases they don’t really believe it. Like an alcoholic who tells you about his drink problem, they say the words because they are the words people expect to hear, but deep down they still believe that they control the drink, it does not control them, and the GUI really isn’t as important as the engine running underneath.

For too many programmers the GUI is the bit bolted on at the last minute to satisfy users and the guys in sales. It is often designed by someone who thinks typing configuration commands into a text file is far more useful than an interactive GUI with trees and checkboxes; that a visual interface can never allow the flexibility and customisation of a simple configuration file. This is all true - if the sole user of the product is the guy who wrote it!

If you don’t think about the user from day one, you will never design a truly great product; you will never design a product people want to use. Even the giants make this mistake. I stumbled across an article the other day on the failings of Lotus Notes, one of IBMs big groupware products everyone was talking about ten years ago. To quote one of the many disgruntled users:

“Notes’s backend functionality has no bearing on us 100m or so end-users. As far as we are concerned the GUI is the system. And boyo… is the GUI client a heap of ill-conceived, non-intuitive rubbish.”

Lotus Notes now has the dubious honour of its very own hate site where its many failings and embarrassments are displayed and dissected for all the world to see.

There’s a lot more competition out there today than there was ten or twenty years ago. If you build a technological marvel and ship it with a shabby user interface, and the competition builds a functional product that looks fantastic, who do you think will win the sale?