On Mar 25, 2014, at 4:07 PM, Coral Sheldon-Hess wrote:

> Some things that came up in the UX discussion (well, the third of it I was
> in) at the breakout session, about how to get your library to be more open
> to UX:

[trimmed, although, I agree on the Steve Krug books]

> I apologize for the self promotion, but not all libraries' cultures allow
> for the "big public test" approach. Mine ... might, now, but probably
> wouldn't have, a couple of years ago.


There's been a recommendation for years that big public tests are a 
waste of people's time ... you don't do that until it's effectively
a release candidate.

Here are the problems:

	(1) there's going to be one or two problems that are the majority
            of the problem reports.

	(2) once everyone's tested out the buggy version, they're tainted
	    so can't be a clean slate when testing the next version.

Most recommendations that I've seen call for 3-5 testers for each
iteration, with 2-3 being preferred if you're doing fast cycles. [1]

Yes, you can run into the one tester with completely unreasonable
demands about how things should be done, but if your programmers
don't see how stupid the ideas are, they should be shown to be
horrible in the next test cycle.

If you run too large of tests, you've got to leave some long 
time window for people to test, someone has to correlate all of
the comments ... it's just a drag.  Small test groups mean you
can run a day of testing once a week and keep moving forward.

-Joe

[1] I'll probably out myself as an old fogey here, but :
	http://www.useit.com/articles/why-you-only-need-to-test-with-5-users/