Usability and design are what jumps out at me. And I must admit, I relish using a system for the first time; be it a new ABM (automated banking machine) or a new pay parking system. These are the rare times I get to jump out of my shell and test a system without any advanced knowledge of its functionality. I get to follow the instructions and if I stumble, I have no one to turn to. I know many people in my life who don’t feel the same. A new system fills them with anxiety, tension, and the fear of failure. Not me, I love it; relish it in fact. So when I have the opportunity to beta test, I gladly accept.

I recently signed on to a few new projects to conduct preliminary usability analysis, and was shocked appalled at some of the UIs programmers wanted to put onto the general public (one program stood out as a monumental calamity). My professors (and professional ergonomists agree) have always told me the enemy of usability are the coders. The tech junkies and gurus that love a challenge, understand the integral parts of a system, and are so deeply immersed in their trade that even the largest niggle seems rudimentary to them (what, you couldn’t figure out that you needed to press the menu button three times, hold shift, and then toggle the left mouse button to pull up the context menu in the advanced options list?). And this fact I always keep in mind. Be wary of alphas and betas that have had no formal usability analysis (paper prototyping, what’s that?), or structural framework in the design phase (rapid iterative design? well we did work on the UI rather quickly!).

I love receptive customers and programmers who actually want to create a manageable and usable program. After all, it is in their benefit to drive up revenue and increase customer usage, is it not? But then you come across the dark side. The developer who insist that users will understand the arbitrarily located buttons. That the program will become intuitive over time. But this is all part of the job. It hones my skills and allows me to be flexible. To work with my clients and around the system itself. Sometimes a complete re-tooling just can’t be done (easily avoided if proper design principles are employed from day one, but let’s not go there). So I let it go and enjoy the ride. But what does burn me, and I’m not going to pull any punches, is when hard-nosed developers make glaring usability mistakes and turn around, publicizing their programs has having an “intuitive interface” that screams usable.

It seems usability has become another buzzword for the industry. Despite no true usability testing every being conducted, developers seem to feel the need to include that little, nine letter word in their program’s sales pitch. It makes me frustrated, angry, and a little sleepy. I understand that my trade is much more of an art than it is a hard science, and in that respect, I want the world to take ergonomists seriously, but if we do our job right, things are seamless. The interface is fluid. The connection between the man and the machine is effortless. So it only hurts us when poor programs are designed poorly and toted as having “usability.” These pieces of software are only as usable in that they can be run on your chosen platform and a user can interact with them. True usability is a synergy between you and the product. It requires extensive testing, change upon change, and may deviate from the developers vision in more ways that one. Sacrifices are made, much blood and sweat is put into it, but the final product is one the user never struggles with. It becomes an extension of the user. And this is much easier said than done (even for the best in the field). But you can see now why the word “usability” (if you ascribe to the above definition) is such a lucrative word to have in your sales pitch.

So please be wary as a user. If you see the term “usability” littered throughout a programs sales pitch, ask them just what they did to make it “usable.” There is more to usability than telling someone the program has it in spades.