[153] in I/T Delivery
Re: Usability Workshop Report & Summary
daemon@ATHENA.MIT.EDU (Susan B. Jones)
Wed Apr 8 14:31:32 1998
In-Reply-To: <v03020904b15148a37abd@[18.152.1.21]>
Date: Wed, 8 Apr 1998 14:32:04 +0100
To: Tim McGovern <tjm@MIT.EDU>, fortoul@MIT.EDU, brendakg@MIT.EDU,
mbarker@MIT.EDU, jjv@MIT.EDU, pbh@MIT.EDU, azary@MIT.EDU,
crockett@MIT.EDU, jlittell@MIT.EDU, eyanow@MIT.EDU, lisanti@MIT.EDU,
ninadm@MIT.EDU, wade@MIT.EDU, hogue@MIT.EDU, rar@MIT.EDU,
delivery@MIT.EDU, ccount@MIT.EDU, ganderso@MIT.EDU
From: "Susan B. Jones" <sbjones@MIT.EDU>
Cc: usability@MIT.EDU
Bravo!
Thanks.
Susan
At 11:37 AM -0400 4/8/98, Tim McGovern wrote:
>At last Friday's Discovery Team Leaders meeting, Greg Anderson asked me to
>send my little report on the Usability workshop around. Here it is...with
>apologies to the plain-text viewers out there, this wasn't intended to be
>any more than notes for myself. Most of this reflects my own opinions &
>action items, and doesn't attempt to be a comprehensive summary of the
>workshop. I hope some of you find it useful. I'd ask that if any of you
>have done similar reports, please share them.
>
>Tim
>
>--------
>
>I attended the Usability Testing workshop held here at MIT on March 25-27,
>1998.
>The instructor was Dr. Judith Ramey <jramey@u.washington.edu>, from the
>University of Washington. I found the approach taken by Dr. Ramey to be
>quite provocative. While there are some hurdles to overcome in
>establishing usability as bona fide work here at MIT, I expect it to be
>valuable in my own work.
>
>The first change in my thinking came as a result of Dr. Ramey's
>redefinition of the whole sphere of usability. She prefers to call it
>Usability Research, to make explicit that it isn't a one-time task
>attached to the end of some product development cycle, but rather an
>on-going effort throughout the cycle. I came away convinced that almost
>anything could benefit from a usability test, at least anything that a
>user comes into contact with.
>
>In a year, if I remember nothing else, I'd like to remember this "poem:" ;-)
>
>Usability is a Business Process
>
>Usability is a structured business process
>that gathers information on specific issues
>from people like the intended users
>to produce product changes
>within a political/cultural context
>which may surface divergent value systems.
>
>It is not adhoc, anecdotal, or comprehensive.
>It is often not quantitatively measured.
>
>Some Other Highlights from the Workshop
>
>We heard and talked a lot about high realism. This is the goal of
>usability testing procedures: to allow the participants to feel, think and
>act as if they were using the product when and where they normally would.
>
>We talked a lot about user classification. This turns out to be a key
>ingredient in good usability work, and doesn't always map 1-to-1 with our
>more convenient handles for users at MIT. For example, for many systems,
>classfication such as undergrads, grads, faculty and staff may not meet
>our usability testing needs, even though that may be the right way to
>segment the market for other purposes.
>
>We talked a lot about the importance of users' mental models. Dr. Ramey
>emphasized that fifty percent of a product is in the user's head. There
>are limits therefore to how usable a given product can be, and there are
>limits to how malleable any given product can be. As part of this, she
>emphasized the need to remember that there are competing intelligences at
>work, and that making assumptions about how users think and feel about
>products without any experimental results is dangerous at best.
>
>We talked at great length about the steps of usability work. We were
>pushed to get past fuzzy, buzzword-laden issue statements, to the real
>heart of the problem. We practiced how to unpack our issues, translating
>them into clear, crip and testable problems defintions.
>
>We talked about getting a clear idea about the object of study in a
>particular situation, as it affects greatly how to state, unpack and test
>the issues. Conventional wisdom holds that as complexity increases,
>testability declines. But if you focus on only those issues within the
>product that produce the greatest risk, you can learn a great deal via
>usability research. Focus on the most common, most critical uses of the
>product. Usability work is great at identifying big effects, not really
>at detecting minor, or subtle, ones.
>
>In some of the workshops, it was very tricky to separate usability issues,
>e.g., access, navigation, etc. from content issues. And to some degree it
>is artificial, and not always possible. Usability, like many disciplines,
>takes some practice, and like any habit, it takes practice to acquire it,
>and to use it facilely.
>
>People can show you more than they can tell you.
>How can we imbed the learning into use?
>Use strategically!!!
>The paradox of the active user.
>Satisficing.
>Let your problem statement dictate your procedure.
>
>MIT Steps that Need to Happen
>
>* We need to validate capturing and showing user experiences
>* We need to validate that no matter where the problem shows up,
> it's still a bug.
>* We need to help MIT make a leap of faith that usability will improve
> products even though it is not an exhaustive, comprehensive, or
> quantitative.
>* We need to support/encourage project/product managers who are inclined to
> define, schedule and allocate resources for usability work.
>* We need to increase the visibility of usability work via various forms
> of communications, written, show-and-tell, personal.
>* We need to start small, do a usability test: see one, do one, teach one.
> Seek small steps of gratification
>* We need to form alliances with like-minded souls at MIT, and elsewhere.
>
>References
>Jakob Nielsen's web site: http://www.useit.com/
>Good web usability web site: http://usableweb.com/
>Usability Professionals Assn.: http://www.upassoc.org/
>Usability Listserv: listproc@hubcap.clemson.edu
> subscribe utest FN LN
