Internet Librarian 2013 – Usability Testing: On Board and On a Shoestring
Sara O’Donnell and Jodie Borgerding
Sara began by talking about the ideal situation of rolling usability testing into the fabric of your website management. But if your institution hasn’t done usability testing in the past, how do you communicate that need to your colleagues? A year ago she was hired into a brand new user experience position at her library. Her goal was to make usability assessment an ongoing systematic process. What’s the value of getting your colleagues involved in usability testing? Support—financial, person-power, professional, intellectual. Colleagues can also offer perspective and help make implementation easier.
Share something about yourself – When you start talking to colleagues about usability testing they likely won’t understand what you’re talking. So demystify it. Talk about the 3-7 users rule, which will likely surprise them. It can also be inexpensive (thank you gifts for participants). It can also be low tech—you can just do this with a video camera, notes, or Camtasia. No crazy stats with such a small sample size. It can also have a fast turnaround time. Forming a taskforce for usability testing can help, especially if they represent a cross-section of your organization. Do pilot testing first to let people get their hands dirt with usability testing.
Bring something cool to show and tell – Make usability testing more visual, tangible, and present for people. She assigned the taskforce homework—to read a couple of Jakob Nielsen’s blog posts (“Usability 101” and “How Users Read on the Web”) and Steve Krug’s book Rocket Surgery Made Easy. She also assigned Krug’s video that corresponds to the book (20 minutes). At the end of pilot testing they did a brown bag session for other interested staff.
Make new friends – Seek out other committees or groups that can help you, outside the library too in your larger institution (university, city, county, school, company). Involve public services staff too—they know how the users are using the website and they know where the stumbling blocks are.
Tell good stories (and listen to good stories) – Communicate your users’ needs and stories. Creative a narrative of the outcome of your usability testing. Usability testing tells you not only the what but the why. And don’t be afraid to touch on those higher order institutional priorities. Make sure you listen to your colleagues’ feedback as well.
Share (your enthusiasm) – If your continually enthused about a project, that transfers to your colleagues. It can be a challenge if you’re doing ongoing usability testing.
After a year in her position she has standing funding, colleagues with an interest in being a part of usability testing, colleagues who propose new directions for testing, and is working on a major restructuring of the library website’s navigation.
Jodie’s portion of the talk focused on doing usability testing with few or no resources. The library maintains their own web servers and so they don’t need to work with university IT. The current website design was implemented in 2009 at the request of the library dean, in response to the university changing its template (library trying to be more in line with the university). The timeline for that change was short so there wasn’t time for usability testing. In 2011 they decided to do usability tests on that design to see if it was meeting the needs of their patrons. They decided on task analysis as a way to evaluate the efficacy of the site. They spent only $30 on incentive flash drives for participants—that was their whole budget. They used Adobe Connect, which they already had access to. Various committee members recruited and observed the participants. It was hard for the librarians to not intervene when observing the participants take a wrong turn or get confused (LOL, totally true).
They did 3 months of testing—two faculty, two staff, and one undergraduate student. There was inconsistency with the recording — only two of them ended up being satisfactory quality-wise. Also, some of the tasks were confusing to users (which is true to life–some of their tasks are confusing to them).
Lessons learned. Task one person to record and observe who actually knows how to use the technology. Test the tasks beforehand, ideally with a non-library person. Revise the task list again and again.
Future plans: The university has adopted a new CMS and design but the library fortunately did not have to move to the new system. An extensive needs assessment demonstrated that the university’s CMS did not meet their needs (it didn’t support forms, third party widgets, etc.). They’re now doing a new redesign of the library’s site, starting with a satisfaction survey and card sorting.