Usability abuse? (Take II)

[Geoff Hart <ghart -at- videotron -dot- ca>]

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.