Historically, usability engineering is done toward the end of a product development cycle, before something goes to code (and, sadly, often not until after), and usually by that point, the only revisions that can be made are rather superficial. If usability testing demonstrates that there are fundamental flaws with the product, well, too late, we’re too far along, so just make this thing as “usable” as possible and don’t worry about it.
For aeons, usability practitioners have tried to extract themselves from these testing backwaters. They’ve rightly pointed out that you are more likely to make something usable if you test iterations of the design, catching fundamental flaws before they’ve become too deeply ingrained.
In attempting to expand their mandate, though, usability practitioners were dissatisfied with simply testing what others have created. And so they’ve attempted to re-define usability in order that it be, well, more interesting.
A case in point: Whitney Quesenbery’s 5E’s Of Usability, Effective, Efficient, Engaging, Error Tolerant, and Easy to Learn. At first blush, it all sounds fine and good. At second blush, one word pops out as not belonging: “engaging.”
Her definition: “How well the interface draws the user into the interaction and how pleasant and satisfying it is to use.” I would argue that this has little to nothing to do with usability. It has everything to do with “desirability”, a valuable quality, but outside the purview of usability.
These redefinitions stick in my craw. It contributes to the territoriality of folks who ought to be simply striving toward common goals. It’s one thing for an individual usability practitioner to desire being part of the team that makes a product more engaging. It’s another thing to translate that desire into a professional pillar. All that this does is further confuse the issue. Ought I go to a “usability engineer” in order to make my product more engaging?
I’ll leave you to answer that question.
This relates to my earlier post on the word “design.” Usability, whether it’s practitioners like it or not, is perceived as a commodity service. We’ve seen again and again “usability” projects simply go to the cheapest bidder. (To some degree, I’m fine with this… usability, on its own, is a commodity. Usability on its own is not worth a lot. If usability isn’t being performed in the context of a larger user experience process, and that within a larger product development process, I can pretty much guarantee that whatever findings emerge from usability will be ignored.)
This is not to say usability engineering isn’t important — it’s critical. But it’s also critical that the practice’s inputs and outputs stay focused on making things *usable*, that is, making it so that people are able to use the product. Able as in physically able, cognitively able.