Is Usability a Feature?
“Usability is a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal.” Wikipedia (April 2006)
When working on a website or web application project I often find myself defending usability as something that is a top priority of the project. To me, usability is a given. I believe that usability is what makes the list of features usable, understandable, accessible, and intuitive (needing little or no outside introduction or explanation - help pages or a manual). This is my belief and one that is not often shared.
When working within a limited or finite budget, usability becomes a bit of a bothersome topic for many. It is not easy to measure and the benefits are not immediately perceptible. Why would someone give up a feature just to improve the usability of the overall application? It also becomes somewhat of a intelligence “test”. This is a paraphrase of a common reaction, “You don’t need to waste time on usability for me, I’ll just figure out how to use it. Instead, put that effort into more features.” Generally, the only time that someone asks for usability, is for a proxy that is perceived not to be so smart like a general audience. As long as usability is perceived as a feature, it will continually be one of the “features” that are first to be cut. However, not creating something with usability in mind, is creating something with the opposite of usability. As far as I know, there is not a term for that so I would like to coin this term as “frustability”. Frustability is often mistaken for other attributes like buggy, complicated, slow, or lack of documentation.
Usability is not a feature, it is an attribute of the whole website or application. If you decide against it to save money, time, or to add features, you are asking for frustability … and frustabililty never quite goes away.
Usability must be recognized as a requirement, must be planned for, must be paid for. Just like all the other types of -ilities. How can you implement usability if you can measure it? How do you know when you’ve got it done? Not putting usability in a requirement spec because you don’t know how to quantify is not a good sign. At that point, usability only exists in your own head. If you want someone to build it, you’ve got to be able to describe it to them, which means you have to be able to quantify it and make it measurable. It is my opinion that until this is done, people will be writing posts like this after every project.
Comment by mckhendry — April 14, 2006 @ 10:10 pm
(cont.) However, when usability is cut out of a project because it is either to hard to implement/measure or because extra features are added instead, this can be attributed to poor prioritization of requirements. Erik Simmons of Intel explained an exercise called the landing zone. Other exercises work just as good. The point is to prioritize requirements correctly, and to identify competing requirements. Not doing this results in frustratability, which has been called by some in the industry as project management malpractice. So again, the key to correcting this is by correctly managing and prioritizing requirements.
Comment by mckhendry — April 14, 2006 @ 10:30 pm
I think you hit it right on the head. What a great comment. Usability is a requirement not a feature.
Comment by Justino — April 19, 2006 @ 6:27 pm