Pigeons can push random buttons

Why does a well-designed user interface seem to drop off the list of priorities when new systems are created?

It's a shame that trade guilds are so out of fashion. Sure, they encourage monopolistic abuse, the forming of cartels and Shaw's famous conspiracy against the laity, but they also give us working stiffs a chance. In particular, there should be a Worshipful Company Of Web Site Operatives. We nearly started one in a meeting in the pub the other night: a rather gruesome collection of old hands gathered from across London to swap war stories.

"They gave us a new system the other day", said one. "Took me half an hour to work out that when the button said "Edit Record" it meant "Save Page". "That's nothing." said another. "Ours has twenty fields to fill in before you get close to editing any text, and then if you're not in the right one of five identical screens you can't change its status." "Can't you set up a template to automate that? Any error messages? Hints?" asked a third. The first two just laughed hollowly, and made the third buy them some more beer. Cheers, chaps.

I know from similar sessions with people from all industries that we are not alone. Business automation, ERP, CRM companies and the ungodly hoards of consultants who darken the skies above the unwary are skilled in many esoteric arts. Powerpoint, project management, writing software, understanding the business model; all these things are proudly trumpeted. You need them all, of course. Data flows one way, money flows the other, and not a penny nor a byte goes uncharted. Who'd have it any other way?

But the systems so produced, whether in-house or out-house (such a good name for consultant-led projects I wonder why it hasn't been more widely adopted), are often as not missing one vital aspect at the edges: a well-designed user interface. Who's entering data when, and why? How long does it take them? How easy can the task be made? It's not that the concept of good interfaces per se is alien: anywhere that people laden with money may alight is polished to the nth degree. It's Hollywood software: the facade is fantastic, but behind the scenes the whole lot's held up with unvarnished planks and six-inch nails.

It continues to amaze me that twenty years after Apple showed the world what well-designed software looked like, most IT departments think the word "Usability" is shorthand for user stopping, activity blighting, information losing, irksome travesty. But then, why would they feel any differently? Companies who spend untold thousands on training and "staff advancement" schemes so inane they pop arteries on a statue would no more hire a usability consultant to actually ask what's needed than get David Blaine in to advise on the staff canteen. It's the same attitude that provides air conditioning for the server room and leaves the grunts at the terminals to wilt in the heat.

Of course, there are many reasons why the employee interfaces get so little attention. Often, things change half-way through the project, and all the resources get thrown at fixing some killer problem that threatens the whole enterprises. All those charts are torn up, tiger teams are set to work hacking away at the databases and glue logic, and a working system produced just three months late that provides 85 percent of the spec. Skin of the teeth rescues are pulled off. Who's got time to waste on fiddling with where fields appear on the screen, or what labels are attached? Who cares that logically connected aspects of tasks are split across three different screens? It works, right? The employees can soon learn how to press the buttons in the right order. How hard can it be?

Such an attitude is dangerously shortsighted. Whatever it is that staff are hired to do, it should not involve learning how to press buttons in a random order. Even pigeons won't do that unless you give them a grain of corn when they succeed. People confronted with horrible interfaces -- and no way of changing them -- are not going to be efficient people. Sure, you can learn how to make it work, but how efficient will you be? How will you be able to transfer your skills to whatever new systems appear? How will new hires, or people covering your job when you're not there, cope?

There is little point in shelling out six or seven figures on a major IT project in the name of efficiency if you never bother to find out whether the people who use it have a fighting chance of being efficient at their jobs. In the great scheme of business, everything boils down to what the employees do and how well they do it: that this never enters the design equation of IT projects is one of the great unmentioned sins of technology.