Les choses sont contre nous—things are against us.  The usability of your most critical IT system is akin to the marmalade-and-toast hypothesis, will the marmalade-side will land on the carpet when the toast falls from the breakfast plate, played out in bits and bytes.  Resistentialism is the belief that inanimate objects have a natural antipathy towards human beings.  If one were to view the marmalade-toast through the glasses of resistentialism one would conclude that the likelihood of the toast laying marmalade-side down increases with the cost of the carpet. So it is with your critical systems.  For most of us, our expensive IT system is laying marmalade-side down on a very expensive carpet.

Your critical IT system has created an air of technostalgia with users yearning for the bygone days when the technology involved a number two pencil and a pad of paper.  Now that you are using your system, do you ever wonder how different the experience of using it would have been if someone had asked for your input about what the IT system should do before they built it?  Would merely asking have solved the system myopia that was brought about by those who implemented it, implemented it without involving a single systems designer?

That this problem even exists is demonstrated by the fact that to use the system required hours of training.  Users sat there like sock puppets listening to the buzzword-bingo put forth by the trainers.  This should have been the clue that none of what they were about to learn was intuitive or self-evident.  The reason they offer IT system training is to explain “This is how you get the system to do what you need it to do,” because without viewing it that way it will not do anything.  Said differently, training is the byproduct of a system, made necessary by the idiosyncrasies of poor design.

The IT system has turned a lot of normally complacent users into stress puppies.  To understand how far amiss the functioning of the IT system is from what the users had hoped it would be all one has to do is observe it being used.  How many users have apologized to a customer because of something related to the system?  “Sorry this is taking so long…If you will just bear with me while I figure out how to do this…When my supervisor returns I will get her to show me how to schedule your appointment.”

If ever there was a time to have employed defensive pessimism, the implementation of an IT system was such a time.  Users went into the project skeptimistic—simultaneously skeptical and optimistic, hoping for the best and certain it would go badly.  As niche worriers, users imagined all the ways that the system would under deliver and would make their jobs more difficult, and they watched their stress portfolios rise.  The forgotten task is that nobody mapped out a way to avert the damage.

That this jump-the-shark problem can and should be corrected by something not much larger than a two-pizza team—a team small enough that it can be fed by two pizzas—seems to have escaped the reason of many. 

Unfriendly, poorly designed software—in particular poorly designed user interfaces—impacts customers and employees.  Customers have the luxury of not using the system.  They either walk away from your firm or they burden your call center.  Employees have no alternative other than to use it.  To them the impact of bad software is a drop in productivity.

Many firms are guilty of treating the productivity drop brought on by poorly designed software as a problem with no solution.  If a problem has no solution it is not a problem, it is a fact.  And if it is a fact it is not to be solved, but coped with over time.  There is way too much coping going on.

The productivity drop caused by poorly designed user interfaces can be undone.  It will not be undone by redoing the training.  It will be undone by assessing the human factors and user experiences of those using the system, by researching how they users want to use it, and by reconfiguring the user interface.

This is not cheap, but it is much less expensive than the ongoing cost of loss productivity.