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/