The Code Rascals are hard at work analyzing and summarizing our first round of usability testing of LibGuides. As we observe participants looking at our guide content, I’m reminded of a webinar I watched last fall called Web Writing with the User in Mind, hosted by Florida Library Webinars. The presenter, Rebecca Blakiston, UX Librarian at Arizona State Libraries, discusses ways that we can create a better user experience by writing better content for our sites. Blakiston begins with premise that people come to websites for content and to perform tasks. At the core of the presentation are 10 writing tips that we can use make it easier on users to complete tasks and find the content they need. The examples she provides refer mostly to content on library websites, but many of the principles can also be applied to our Research Guides. I’ll recap a few highlights here, but if you’re interested you can view her full slide deck.

Tips for Writing on the Web from Web Writing with the User in Mind

1. Know how users read on the web. Deep reading is rare and visitors are likely to scan to find content that’s relevant. Users also tend to focus their eyes on the left side of the screen, skimming down, but staying toward the top of the page.
2. Know your users. Use analytics data and talk to your users to better understand what they need need.
3. Simplify your text. Use no more than 25 words per sentence, use active voice, and avoid adverbs for stronger sentences. Fragments and shorter paragraphs can help users scan your content quickly.
4. Be Human. Use a conversational tone as if you were talking to the user at the reference desk. Write like you talk. Test by reading your text aloud to see how it sounds. Cal Poly San Luis Obispo library’s website is a good example of a conversational, but not overly casual, tone.

Thinking back to LibGuides, our guide text, including database and link descriptions, impact how users interact with our guides. One place we may do well to write more succinctly and intentionally is in our database descriptions. In our usability test, we observed that participants do read database descriptions (some more deeply than others) when selecting a database, signaling to us that we need to be thoughtful about what goes into the descriptions. We should customize database and link descriptions to the guide’s purpose and include details that tell the user how to use a specific resource or why it might benefit them. With course guides, for example, we can use language from course assignments to craft custom database descriptions that connect resources to specific course themes or assignments. In my Meaning of Madness:SPSY 0828 guide, I’ve included language from course assignments in my box titles, and I’ve attempted to keep my database descriptions short and related to the assignments. Writing custom descriptions also forces us to be more cognizant of which resources we’re presenting to users.

If you do add a custom database description, remember to set the description to “Display beneath item title” rather than hover, so that the user can see the description!

We’ll have another post later in the semester summarizing our findings alongside discussions of other best practices.

More on writing for the web from Usability.gov.

The Code Rascals turned their attention to user experience in late Spring with the intention of conducting a usability study of the Libraries’ Research Guides over the next year. To prepare, we took a break from our more tech-focused tutorials and worked through a Lynda tutorial called Foundations of UX: Usability Testing and Treehouse’s Usability Foundations course.

Overview

The purpose of our usability study is to understand how undergraduate users execute research and discover resources in our Research Guides, address system-level usability issues, and to generate a list of best practices for guide creators. We chose to do two to three rounds of testing and study only five participants at a time. This decision was based on findings from the Nielsen Norman Group that “the best results come from testing no more than 5 users and running as many small tests as you can afford.” The idea is that the same usability issues pop up again and again with each participant, and you eventually stop discovering new problems. This approach also gives us the flexibility to make small changes to Research Guides along the way and to re-design each test to probe more deeply into usability issues. To design our study, we began by generating a list of research questions to guide the creation of usability test tasks and to determine specifically what we wanted to know about the way users interact with Research Guides.

Recruitment & Testing

In October, we concluded the first round of usability testing. We recruited in early Fall semester using fliers, social media posts, and digital signage. Interested undergrads submitted their names in a Google Form and Jackie coordinated final meeting times through email. Participants were given $50 Barnes and Noble Gift Cards for their time.

Five users participated in usability tests that ran from 35 minutes to 1 hour. Each session took place in a breakout room in the Libraries’ new Digital Scholarship Center. Our set-up included a Mac laptop, mouse, and external monitor for the facilitators to observe as the participant navigated through the usability tasks. The sessions were also broadcast to a library conference room where other library staff gathered to observe the live sessions. We asked observers in the conference room to note usability issues and gave them the opportunity to ask follow-up questions of the participant. Two Code Rascals facilitated the test in the DSC breakout room while at least two others facilitated observation in the conference room. Sessions were also recorded using Quicktime, so that we could conduct a more thorough analysis later. While each test highlighted a number of usability problems right away, we also wanted the ability to re-watch the tests later in co-viewing sessions as this method provides rich insights that may be overlooked during the live session.

Participants included

• 1 Freshmen Biology major
• 1 Sophomore Film major
• 1 Sophomore, Actuarial Science major/Spanish minor
• 1 Freshmen Secondary Education/English major
• 1 Sophomore Psychology major/Italian minor

Overview of the test protocol

We began with a few basic questions including

• What is your major and department?
• Have you used the library website to conduct research before?
• Have you attended any library workshops since you’ve been at Temple?

We then asked participants to complete a series of tasks using the “think-aloud” method or to “literally talk us through what you’re doing and what you’re thinking.” Each participant explored Research Guides freely for 2-3 minutes and gave us their general impressions, completed 7 research-based tasks in different scenarios, and completed an “XO” test where they circled things they liked and crossed out things they did not like on print outs of a subject guide and course guide in their major or minor. The full usability script is available here.

The Rascals are still in the midst of analyzing each recording. We’ll report some preliminary findings here, though look for a more thorough analysis and report at the end of the academic year. Next steps for us include designing a second round of usability testing for Spring semester and generating best practices for guide creators based on the findings by early Summer.

I recently stumbled upon a post in ACRL’s TechConnect blog from librarians Margaret Heller and Will Kent at Loyola University Chicago describing their migration to LibGuides 2.0. Their implementation of ‘sticky tabs‘ intrigued me. They implemented the Affix plugin for Bootstrap (the framework on which LibGuides is built) which fixes LibGuides’ tabbed navigation to the top of the page as the user scrolls through the guide content. The tabs are more visible, and the user doesn’t have to scroll back to the top to navigate to another section of the guide.

After some preliminary investigations, the Code Rascals decided that sticky tabs looked simple enough to implement. Jenifer located some helpful tutorials on the affix plugin, and we spent one of our meetings tinkering with incorporating the code into LibGuides’ customizable settings. After some trial and error (and frustration), I finally had some success a few days later!

I’ve noticed on many of my own guides that the homepage has the greatest number of hits, while other pages and subpages have far less traffic perhaps suggesting users are finding what they need on the homepage, or perhaps that they don’t notice the navigation to other sections of the guide. Without presuming too much about user behavior, here’s hoping that the sticky tabs increase user awareness of content beyond what’s visible on the homepage. The sticky tabs should at least ease navigation through the rest of the guide.

Try the sticky tabs out yourself here and let me know if you have any feedback. We plan to introduce a template that you can select for your guide if you’d like to start using sticky tabs!