Usability abuse? (Take II)

Subject: Usability abuse? (Take II)
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Sun, 14 Nov 2004 15:29:23 -0500


Andrew Plato responded to my examples of problems reported by users (specifically, for a car): <<This isn't usability testing, that is griping.>>

No, it's usability testing. All that a usability expert does in _conducting_ a usability test is collect a list of what you call "gripes"--both those reported by the test subject and those observed by the expert. If a particular comment appears sufficiently often, then it's a real problem, not just a gripe.

The definition of usability is simple: "_I_ can use it effectively". Note that the "I" refers to the person intended to use the product. (If you're asking people who are unqualified to use the product, you're missing the point.) When that person can't use something effectively, it's less usable than it should be, and possibly even unusable.

<<What you find annoying, clumsy, or even elegant might not fit with the majority.>>

Which is why my original message stated clearly that "If the way you work is ***broadly representative***, and you experience problems, then many other users will experience similar problems". Clearly, if you're the only one with a particular problem, then the problem is more likely to lie with you than the product. But not always---sometimes you're the power user who pushes the product until it breaks.

<<Casual use is NOT a replacement for industry expertise.>>

In fact, it's better than industry expertise ***if the product is designed for the casual user***. If the product is designed for experts, then the casual user clearly isn't competent to judge whether it's usable.

<<you cannot be a usability expert from just using a product.>>

Nobody ever said you could. What I said was "You don't have to be a usability expert! All you have to do is use the product." If the product is intended to be used by you, and it doesn't work well, then it's not usable from your perspective. If a significant number of others are similar to you, then it's a broadly based problem that needs to be fixed.

<<Griping about a product is not synonymous with usability analysis.>>

Nobody, least of all me, said it was. The goal of usability analysis is to produce a product that, when tested by its intended audience, has fewer usability problems than might otherwise be the case. A good usability analysis by an expert who is familiar with the audience can save lots of money and time when it comes to the actual testing. It cannot take the place of that actual testing.

The interesting thing about usability analysis is that it's still a very immature field. Jakob Neilsen and others have repeatedly tested products (most recently, Web sites) based on the "best practices" usability heuristics espoused by recognized experts. The experts rarely agree on all the problems, and often disagree quite markedly, though there's usually considerable overlap in their judgments. The judgments, taken as a whole, do a good job of predicting the actual user's experience, but often miss key problems. This doesn't make the analysis useless; it just means that in the end, the only definitive judges of usability are the people who will use the product.

<<I think you're misleading writers saying they can do this with no training or experience.>>

Note that I'm not saying that writers can be usability experts with no training or experience. What I am saying is that anyone who uses a product and pays attention will be able to detect things that simply don't work well. This requires no expertise whatsoever, any more than tripping over a poorly laid floor requires expertise.

<<Griping is a great way to get yourself ignored, shoved aside, and disrespected.>>

Which is why I emphasized that "simple claims won't be accepted until they recognize you as someone whose opinion is worth heeding". It's not about griping: it's about reporting something that you perceive as a problem, explaining clearly why it's a problem and what might be done to solve the problem, and justifying your case. If you can't justify your case, you won't win that particular battle. If all you do is complain, without justification or proposing a solution, you lose the respect necessary for them to listen to you.

<<And don't detangle this into "well what about pointing out spelling errors in the GUI." Not the same. Correcting a minor error like that is not the same as judgements regarding the usability of an application.>>

That's a tautology and thus meaningless: if it's a minor error, it's clearly not a usability problem. If it's a significant error, then it is a usability problem. But that's less likely to happen due to typos than it is due to poor word choice.

<<In order to do that [report a problem and request a fix], you must have some authority. Authority is never given, it is earned. Which means you need to earn some authority over usability on the project.>>

First, it's not about authority; it's about persuasion. If you can make a strong case, you acquire a form of authority because people are willing to listen to you. If you're the manager, you acquire authority not because you can make a case, but because you can fire anyone who doesn't do what you tell them. No good manager works this way, but that's the reality of power.

<<Furthermore, usability is another area that writers notoriously use to avoid their real job.>>

It's never an either/or situation. It's trivially easy to spend 5 minutes with a developer demonstrating a problem and explaining why it's a problem (if that's not obvious). This doesn't stop you from documenting the product. On the contrary, fixing a problem during the documentation phase often makes it faster to document the product than might otherwise be the case; you can end up working faster by reporting problems than you can by ignoring them and trying to write your way around the problem.

In the four products I used to document, I routinely reported usability problems to the developers, who were generally quite happy to adopt my suggestions on how to fix them. Why? Because I presented the problem diplomatically, demonstrated why it was a problem, suggested how to fix it (in several cases, also pointing out how they could make debugging and future code maintenance easier by adopting my suggestion), and worked with them to come up with a solution they had time to implement. It's all about gaining enough respect to be listened to; you won't always win, but there's no reason not to try.

--Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!

RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.



Follow-Ups:

References:
Re: Usability abuse?: From: Andrew Plato

Previous by Author: Text enrichment software tool?
Next by Author: Usability abuse? (Take III)
Previous by Thread: Re: Usability abuse?
Next by Thread: Re: Usability abuse? (Take II)


What this post helpful? Share it with friends and colleagues:


Sponsored Ads