I’m always looking to find out about the tools and techniques that people are using to improve their websites, and particularly how they go about testing the user experience (or UX) to make sure that they can make steady improvements in their site.
So I’m a regular follower of some of the work that is going on in academic libraries in the US (e.g. Scott Young talking about A/B testing and experiments at Montana , and Matt Reidsma talking about Holistic UX). It was particularly useful to find out about the process that led to the three headings on the home page of Montana State University library, and the stages that they went through before they settled on Find, Request and Services.
A step-by-step description showing the tools and techniques is a really valuable demonstration of how they went about the process and how they made their decision. It is interesting to me how frequently libraries seem not to pick the right words to describe their services, and don’t pick words that make sense to their users. But it’s really good to see an approach that largely gets users to decide on what works by testing what works, rather than asking users what they prefer.
Something else that I came across the other week was the term ‘guerilla testing’ applied to testing the usability of websites (I think that probably came from the session on ‘guerilla research’ that Martin Weller and Tony Hirst ran the other week that I caught up with via their blog posts/recording). That led on to ‘Guerilla testing‘ on the Government Service Design Manual (there’s some sense of slight irony for me about guerilla testing being documented – in some detail – in a design manual) – but the way it talks through the process, its strengths and weaknesses is really useful and it made me think about the contrast between that approach and the fairly careful and deliberate approach that we’ve been talking with our work over the last couple of months. Some things to think about.
Reflections on our approach
It’s good to get an illustration from Montana of the value of the A/B testing approach. It’s a well-evidenced and standard approach to web usability but I know that it is something that we’ve found difficult to use in a live environment as it makes our helpdesk people anxious that they aren’t clear what version of the website customers might be seeing. So we’ve tended to use step by step iterations rather than straightforward A/B testing. But something I think to revisit.
The piece of work that we’re concentrating on at the moment is to look at student needs from library search. We know it’s a pain point for students, we know it’s not ‘like Google’ and isn’t as intuitive as they feel it should be. So we’re trying to gain a better understanding of what we could do to make it a better experience (and what we shouldn’t do). So we’re working with a panel of students who want to work with the library to help create better services.
The first round tested half a dozen typical library resource search scenarios against eight different library search tools (some from us and some from elsewhere) with around twenty different users. We did all our testing as remote 1:1 sessions using Teamviewer software (although you could probably use Skype or a number of alternatives) and were able to record the sessions and have observers/note takers. We’ve assessed the success rate for each scenario against each tool and also measured the average time it took to complete each task with each tool (or the time before people gave up). These are giving us a good idea of what works and what doesn’t.
For the second round a series of wireframes were created using Balsamiq to test different variants of search boxes and results pages. So we ran a further set of tests again with the panel and again remotely. We’ve now got a pretty good idea of some of the things that look like they will work so have started to prototype a real search tool. We’re now going to be doing a series of iterative development cycles, testing tools with students and then refining them. That should greatly improve our understanding of what students want from library search and allow us to experiment with how we can build the features they want.
Libwebrarian's Blog 