Study plan

Background: The University of Waterloo Library has a massive collection of virtual resources, with several million ebooks, electronic articles, standards, theses, and more accessible from its catalogue. Library staff often bulk add resources to the collection, but this comes with a margin of error. If information is incorrectly delivered from a publisher, such as misspelled or incorrect URLs, this will block access to resources the Library has purchased. Considering the size of the virtual collection, the Library depends on users to let it know when they encounter a broken URL.

In the year since the 'Report a Problem" button was created and placed on each catalogue record, library staff noticed the button was primarily used by other library staff. In conversation with staff, they shared an assumption University of Waterloo students will reach out if they are unable to access an electronic resource (article or e-book) from the catalogue. Considering the numbers didn't match staff expectations, I wanted to test that assumption and to learn why a student may not report a broken catalogue record through the 'Report the 'Problem' button.

Research Question:

Consulting with IT and Cataloguing library staff who manage the catalogue, we agreed on the following research questions:

• Do students "see" the 'Report a problem button?

• Does the 'Report a problem' button function like they expect?

• Were there any UI issues?

Method:

We decided to run a guerilla usability test using a catalogue record with a purposefully broken URL.

Six participants, were tasked to open a chapter from an assigned e-book and asked follow-up questions on their experience.

We had three criteria for success: Find the catalogue record, find and acknowledge the "Report a Problem" button, and use the "Report a Problem" function to report the broken catalogue record.

When it came to the "Report a Problem" button, most felt it would be their last resort. Part of this reluctance to use the button came from feeling reluctant to share personal information, not wanting to be a "bother" to staff, or felt the report would be better coming from a professor or faculty member, and not from them.

Recommendations

From learning why students may feel reluctant to report broken catalogue records, recommendations were shared out to related departments to try to reduce these possible barriers. These recommendations included:

• Adding timelines for when staff may respond or action be taken on a report

• Reducing the number of required questions on the form

• Creating messaging through the library's marketing and student engagement teams to try to normalize the use of this button and to encourage the reluctant user.

Post guerilla usability test

This study was just one example of the unexpected insights that can occur by asking questions and testing our assumptions of users. By asking "why" and probing questions to explore participant's behaviours, I was able to uncover the block our design was creating on the students who were trying to access broken electronic material!

Report a Problem: Presentation delivered to stakeholders

Return to the Research Portfolio page or view another case study: Use of the Library's lobby, Diary Study, or Focus Group