Paul W. Frields wrote:
Well hush my mouth, this sounds great. But the key factor is the
"target" part -- and mostly the studies that I've seen users advocate is
a limitless problem set, without boundaries. So I mistakenly brought
that knee-jerk bias to this conversation, which is my own fault.
Ahh, I didn't mean it that way!! I have to totally agree with what you
originally said, "There is much more to usability testing than simply
making lists of what people would like to see."
I think a lot of people have the perception:
1. Do usability tests
2. ???
3. PROFI^H^H^H^H^HThe next ipod!!!!11
I more wanted to highlight with the right focus (a very targeted scope
for testing; you need to know what finely-grained and well-defined tasks
that you've identified as the most critical for a specific application)
usability testing can be something that ANYBODY can do and doesn't need
to involve a lot of time or $$. However like you hinted at:
1. "Usability tests on Fedora" = $$, time, data not useful since it'll
reflect on the Fedora of three or four versions ago by the time a study
of that boundless scope is done (and since the tasks may not have been
chosen strategically it might give you data on the usability of tasks
that aren't even critical for your users to be able to complete)
vs.
2. "Usability test to determine how difficult it is for a new Fedora
user to download, burn, and install Fedora in order to try it out" -
much, much easier to do. It's got a well-defined scope, is a task that
is quite strategic and critical for Fedora's success (if people can't
even download and run it, they would never see all the improvements in
Fedora itself)
I do apologize for beating a dead horse :( but as someone who has a
usability and design background, I do get a LOT of questions on why we
don't just usability test Fedora or usability test Satellite or
usability test this or that to solve problems, so I think this thread
maybe hit a nerve. :) I think there are a lot of misconceptions about
how usability testing works and what you actually get out of what you
put into it (you get a list of problems, not answers to them). So I
thought it would be useful to make it more clear why simply 'usability
testing Fedora' is not really something that can be done.
I think the more key thing is to identify those strategic tasks we want
Fedora users to do. It would help identify the most important
development priorities. Even without usability testing, we probably
already have backlogs of bugs and complaints about those tasks that are
hidden amongst the body of bugs and complaints about less-important
tasks...
And I think identifying the strategic tasks flows from what Fedora's
goals are. Who do we want Fedora to be when it grows up? How important
are less-technical users vs more savvy developers? How important is
server capabilities vs desktop capabilities? The answers to these kind
of questions definitely influence what tasks you want users to be able
to accomplish most easily. I think projects like the Fedora foundations
and the marketing plan that was done a while back (I can't seem to find
it on the wiki now :() are really key for defining this.
~m
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
