Feedback on Usability

A while back I responded to your conversation about design strategies where I essentially said my main credo was to do what makes sense for the project at hand and don’t be blindly bound by conventions or practices which may not help, and in fact may hinder, the project. I would similarly say that when considering usability that this approach largely applies, but it can’t be everything. Unlike program logic which is objective, usability involves the perception of the end user which makes it subjective. Unfortunately, once you introduce subjectivity into the equation you have just created the scenario where 100% of the people can’t be pleased 100% of the time. Hence the irresolvable scenario noted above. So what to do?

If you’re going to limit your end user’s experience to just using the program (you had suggested introducing user training in your original post) then I suppose you try to find the happy "relative maximum" in the bell curve of the objective (logic) vs. the subjective (perception) in terms of usability and effectiveness.

For example, my users. I provide data driven applications in a hospital setting. I am not bashing my users, but the vast majority of them do not understand data concepts or how to work with data. As a consequence they can’t/don’t give complete specifications on how they want the program to behave; the specifications are (and I am simplifying this greatly) "Give us something that does this". Of course, when I push for clarification or try to present potential pitfalls with the request I am sometimes resented as being obstructionist or being too detail oriented and am told "We are not the programmer, you are and it is your job to figure out the details". This is difficult because sometimes what they say they want by its nature violates data integrity or has the potential to cause hidden errors in the data that may never be found; not good in the regulated medical industry.

My point is not to rant but to demonstrate the mindset of many end users. In the hospital environment my primary duty is to the patients and their safety (ensuring accurate data) and not to my end users. Of course, with their all but empty and vacuous specifications, I give them something which maintains data integrity; however, it is not what they want; they don’t know what they want just that this isn’t it. In one instance I tried to present a user interface which made all the sense in the world to me (a person thinking in terms of the global domain of the data and wanting to ensure data integrity and functionality). The response was lukewarm at best. Using the base of what I gave them they made their feed back to cut out certain parts which would save them 2-3 key strokes or mouse clicks per patient; however, in doing so they lost flexibility to audit/validate data; that task would be left to manual requests of me to check the backend database…so much for me getting hit by a bus…

The point of the last paragraph was to demonstrate 2 completely different interpretations of what "usability" means: my perspective of complete information and flexibility to understand the data vs. the perspective of "don’t confuse me with the facts" and "as few mouse clicks as possible". Somewhere in between had to be the happy medium.