At Grand Valley State University, we do monthly usability testing on our website. (Yes, I said monthly.) I’m going to just let that sink in for a moment.

We don’t have a huge budget for testing; our direct costs run about $30-40 a month. We don’t have a huge Web team; it’s just me and one 10-hour a week student. We don’t have a dedicated room for running the test or for doing observation; instead we use my office and a conference room. We don’t have a lot of technology dedicated to the test; we use my laptop and a decommissioned MacBook from 2008, along with a USB microphone. We just know that usability testing and the constant, iterative improvements it helps us make to our website are important, so we make it work.

I was fortunate when I arrived at GVSU last year, because the staff already knew that they needed someone to perform regular usability tests on the website. In normal universities, that means once a year the Web team dusts off some really expensive software 1 and takes the storage boxes out of the usability testing lab, and sets up a big, 3-day event with a lot of statistics-collecting and silly question writing and whatnot. Nothing on the website ever gets changed because of these tests, but someone will probably wrangle an article full of charts and graphs out it, and maybe a few conference presentations where they fly across the country to read a bullet list out loud to a room of over-caffeinated librarians. The reason university libraries run their usability tests this way is because the website is made for the librarians, so why wouldn’t the usability tests benefit the librarians as well?

I have a mantra that I repeat in meetings and presentations. “The website is not for librarians.” Say it with me. If you’re a librarian (as I am) look in a mirror and repeat after me:

“The website is not for you.”

The website is for our users. Our students. Our faculty. And yes, our staff. But mostly for our students and faculty. Look at your average university website and see what sorts of things you can do on the site. You can probably read an FAQ with 300 entries, see folders full of policies, choose from a number of non-user friendly research tools (Database A-Z lists, Federated search engines, library catalogs, etc.)2. That’ s because all of this stuff is what we librarians want, and what we like to do. We love writing policies. You know who never looks at policies? Our users3. We like looking at Database titles. We know, for instance, that you’ll find different things in a Knovel database than in Lexis Nexis. But you know who doesn’t know that, and frankly, shouldn’t have to care? Our users. They hate Database A-Z lists. Don’t believe me? Try asking one of them, or better yet, have them use one in a usability test. I won’t even say “I told you so.”

Here’s what our users do on our websites: find stuff. That’s it. And when I say “stuff,” I don’t mean policies, old assessment reports, strategic plans, and mission statements4. I mean articles. I mean books. I mean sources that will help them with research. They want to find that stuff and they don’t understand why it’s so hard. If they want a book, we tell them they need to use the catalog. If they want to find an article, they need to know the best subject-specific database (and all of its idiosyncrasies). Looking for help with your research? You need to know that Subject Guides or Libguides is the right place for you. This is ridiculous. Users have enough going on in their lives, they shouldn’t have to know all of this library jargon. They want to have one big fat search box that they can find stuff in, like Google. How do I know this? Do I have any statistics or fancy reports to back this up? No, but every month I sit down with actual users of our website to see how they find stuff and to ask them what they want. And I can tell you, they’re not itching for more policies pages.

This frustration brought GVSU to Summon. Summon is a web-scale discovery service from Serials Solutions. It’s not perfect, by a long shot. But it’s a start. And one of the first things I set out to do when I got here was to see how our users were using it. We’d already spent a good deal of time looking at usage statistics and comparing and contrasting things. Statistics can tell you a lot, but they can’t give you the context of why or even how someone uses something. The only way to find out how and why someone is using your website is to sit down next to them and watch them. Ask some questions. And then determine what got in their way and try to fix it. That’s it. By shedding the usual statistics-and-report dance, we keep the tests focused on what really matters: improving the website.

Google is great at improving its site to be better for users. It has to. One of the most powerful tweaks they’ve made in the past few years shows you results from Web, images, shopping, and places all from a single search. Summon does show results from databases, our catalog, digital collections, and LibGuides all on one screen, but it does so poorly. Based on watching our users interact with Summon during our usability tests we’re working on improving the search results screen so that users don’t need to know which tool is appropriate before they search. A few places have already done this to good effect. The University of Michigan does this with their search tool Deep Blue, although they do not use Summon, and do not search articles. (They have written a lot about usability testing on their Deep Blue, though.) North Carolina State University has one of the cleanest search results screens, pulling articles from Summon, books from the catalog, hits from the website, as well as database and journal recommendations.

This kind of change is not just something that we’ve heard our users say they want. We could scrap usability tests and do surveys and get that kind of information. Instead, this is something we see is needed because we watch our users trying to use our site like this now, even though the capability isn’t there yet. We’d never know that if we didn’t watch a few people use our site every few weeks and then try to fix their problems for the next time. It’s another channel we’ve opened in a dialogue with our users about how we can help them be awesome at their work. Running regular tests reminds me that the library website isn’t an end in itself, another trap libraries fall into. (Who goes and searches library websites for fun?) The library website is a just tool that should get out of the user’s way and help him or her do her job.

If your library website is like most you can probably also get to any page on the website right from the home page. Libraries love links so much that most of them look like spam link farms, designed to trick Google. Every other successful website on the planet gave that up in the late ’90s, but not libraries. We librarians _like_ to see a big list of resources because it makes us seem more relevant. “Look at all this good stuff we have! We’re not just for novels anymore! We won’t shush you, either!” ↩

I have a theory that policies exist on the website so that public service staff have something to point to when they tell a patron they owe money, or can’t do something like eat in the library. “I’m sorry, but eating isn’t allowed in here. It’s stated clearly in our policies, on the website.” ↩

I know, your provost wants those things on the website. That’s ok. Just understand that no one besides other provosts and librarians will ever look at them and you’ll sleep better at night. ↩