Re: What has LIS learned?

> "Is that a call for knowing how to do it, or a call for how we can do
> it in the library world?"

On 5/4/07, Andrews, Mark J. <MarkAndrews_at_creighton.edu> wrote:
> YES!

There's bucketloads of information out there on the process and
philosophy itself. A google search yields months of reading ;

   http://www.google.com.au/search?q=user-centred+design

Some of them talk a lot about usability, but I think that's to cash in
on the buzzword bingo that many consultancies play. If you really want
to get into it, read a few blogs from UCD people (you'll find many of
them on the SIGIA mailing-list). As a starter, try ;

   http://www.usabilitynet.org/tools/gettingstarted.htm

The main rule is; Test early and often with real users. As explained
earlier, don't be afraid of exposing end-users to the design process.
A lot of people, organisations and companies have a tendency to hide
the design process itself from users, and there are many theories to
why, such as hiding poor processes or poor ideas, being secretive and
giving themselves the feeling of being superior, or they don't know
any better or think that since it hasn't been traditional to do it
they can't do it.

The problem is that it is indeed very traditional; did you ever learn
to make apple-pie from your mum or grandma/pa? That's where it starts;
you are involved in the process of baking that pie. Some people
wouldn't allow anyone to alter the recepie, but in a UCD that's
exactly what you do; you alter the process to better fit the tastebuds
of the person. of course, you as the professional, who's baked
hundreds of different pies, knows how to bake pies, but only the user
knows what the best taste is.

Another obstacle seems to be project management, especially the
waterfall models used in Prince/2 and - dare I say it? - especially in
libraries. First rule here is to a) cut down the length of an
itereation, version, release, etc, and make everything smaller, and b)
insert a real user-test at the end of that small release. Part a) does
already exist in most project management, but they need to be made
shorted. Part b) is rarely heard of, but it's not hard to add to
existing processes.

User-testing in itself is a couple of books worth, but get ahold of
this one which I've used for years and is the one I keep going back to
;

   http://www.usabilityviews.com/uv007192.html

For user-testing, a lot of people test their own stuff, so you fire up
a new release, tell your people to test it, and the PM and some
business-owners test it out. That's wrong, as they are not end-users;
they are, in fact, often the worst people to juge the usability and
user-centred part of your designs. Get real users, and we in library
land are extremly priveledged to have rooms full of people who usually
would love to help us out. Grab them, give them a book voucher, test
your systems.

There's the expression of "hallway testing", which basically means
"drag the first person you meet in the hallway in to just try out
where you're up to", and even that will squash 50% of most
embaressements. :)

Anyways, I could go on for months on this topic. Maybe I should write
something up, but feel free to ask questions and hassle me to either
talk more, or write more about it. :)


Regards,

Alex
--
 ---------------------------------------------------------------------------
 Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------