When Does the Library Close Today?
Rethinking the experience of checking library hours
Siri knows when your favorite restaurant opens tomorrow. But at an academic library that is open to the public, even a staff member may struggle to tell you the time you’re supposed to leave.
The University of Arizona Libraries offers five campus libraries, each with different hours of operation. Anyone can use any of the libraries — just not anytime, as some locations are only open to certain users outside of normal hours. Plus, the library hours may be different during certain times of the year. Yes, we all need more time during finals!
Aside from the door signs, the UA Libraries has always had web pages to show hours of all its locations. Since the server that hosted the legacy library hours module was set to be retired, a team at the library started to revisit the pages that had served us for almost a decade.
Here’s the story of how we redesigned the experience for everyone.
Motivations for the redesign
“How do I check the hours? I just walk to the door and read the sign.”
That’s probably the last thing we wanted to hear, but clearly there were some issues with the legacy hours page. Through preliminary user research, feedback from students, faculty, staff and community members pointed us toward the following issues:
- The interface looked outdated and lacked responsiveness. The quirkiness of the mobile interface added a barrier to the experience of checking the hours on the go.
- Some of the hours were inaccurate or misleading. An example is the confusing Sunday hours: CatCard (the university’s campus card) holders can access the Main Library any time from 9am on Sunday until 1am on the following Saturday. However, while the library doesn’t open until 9am on Sunday, the hours of that day had 24 hours in it. Similarly confusing language also showed up whenever there was an exception to the regular hours.
Aside from the issues that emerged from user research, stakeholders from the library’s Access & Information Services also hoped to see an interface that clearly highlights the hours for different user groups. This was particularly crucial for the Health Sciences Library, which only opens to UA Health Sciences affiliates instead of any CatCard holder outside of public hours.
Defining the scope: Let’s all write user stories
Collaboration found its place in every step of this project. Beginning in the planning phase, the team incorporated stakeholders’ needs through user story workshops. Team members were invited to gather around a table and write down user stories they could think of, using the following format:
As ____ (a persona), I want to ____ (an action), so that ____ (an outcome).
Similar or relevant user stories were merged into one user story. The team then prioritized them and used the top candidates as the building blocks for this project.
Here are the three user stories that we decided to pursue:
- User story #1 (weekly view): As a library user, I want to know when the library will be open so that I can plan my week out accordingly.
- User story #2 (monthly view): As an out-of-state Special Collections user, I want to know what the Special Collections hours will be in a few months so that I can plan a future research visit.
- User story #3 (homepage widget): As a student, I want to know which libraries are open now so that I can study for my test tomorrow.
To specify detailed requirements, the team also assigned conditions of satisfaction to each user story.
Prototyping: No detail is too small
Collaborative prototyping: Everyone gets to design
Something else we did to bring all creative minds onto the same page was adding collaborative prototyping to our design process. For each user story, team members gathered around the same table to sketch a prototype in their mind on a piece of paper. This varied in format from a full interface, a couple of elements, a feature, or simply some content that they had in mind.
Each piece of work then went up onto the whiteboard—not to be judged by drawing skills, though! The team highlighted features in each prototype and grouped them based on features they shared. Another round of candidates was selected and brought into the next step: UI prototyping.
UI prototyping: Come “stalk” us on Figma!
In order to establish a single source of truth for development, we started from the lowest fidelity prototypes—paper sketches we brought back from collaborative prototyping—and worked our way up to a high fidelity prototype. Thanks to the collaboration features offered by Figma, the rest of the team was able to “stalk” us in real time and give us feedback quickly.
We also created a component library that follows Atomic Design process using Figma. This helped cultivate a joyful design handoff experience as it brought more flexibility when the team addressed UI changes. Plus the components can be easily reused for future projects too!
UX writing: It’s all about being clear and concise
A helpful tool shouldn’t require much thinking when being used. In order to address the issue of confusing UI text, we gave much thought to the choice of words used in the interface.
Going back to the Sunday hours example: Any CatCard holder can use the Main Library starting from 9am on Sunday until 1am on the following Saturday. Although the library operates overnight on Sunday, it isn’t technically open 24 hours—and we became really creative when crafting short but effective phrases to describe the hours on that day.
We ended up going with “opens at 9am (stays open)” for Sunday hours, which was a description that worked for over 90% of test participants. We also addressed similar issues for Friday and holiday hours by running comparative testing on multiple variations of language.
Validating the design: Test, iterate, and test again
Test setup: Tiny Café
We used Tiny Café as our main method of conducting usability testing and getting feedback early and often (from real people we could talk to). At this pop-up fixture that we set up weekly, snacks and beverages were offered to anyone who stops by and is willing to spare a few minutes to complete our task scenarios.
The task scenarios were carefully written to probe the corresponding research questions. We made sure they were always bite-sized, so that they wouldn’t take too much time to complete. In order to measure success rates, an expected outcome was assigned to each task scenario and was compared with the test participant’s conclusion. We also recorded and/or jotted down the specific steps the participant took, along with their answers to follow-up questions.
The audience switcher: Thank goodness we tested that
The audience switcher is a great example of the importance of testing. Since specific user groups could have after-hours access to some library locations, we created this UI element to help the user find correct hours that apply to them.
In the first iteration, this was done through clicking on separate buttons (as shown above). To our surprise—when test participants were asked to find hours for a different audience group, most people never noticed these buttons! Even the few people who did find them had trouble telling which button was selected. In the end, this design only scored a 15% success rate. That sounds devastating, but it’s exactly why we test!
After trying a few alternatives, we discovered the tab-style interaction was the one that scored the highest point during testing. No doubt that ended up in the final design. (We guessed this could be due to users’ familiarity with the common tab UI in web browsers.)
We also made a back up plan in case the audience switcher still fails to catch attention. “Positive redundancy” was introduced to the interface through the addition of a short note on the bottom. For users who are looking at extended hours, this note serves as a reminder that public hours may be different. We tested again after implementing these two changes and the success rate surged to a whopping 88.5%!
Results: 😎
We now proudly offer three ways to check the hours, in correspondence with our three user stories.
The weekly view gets you ready for the next seven days.
The monthly view has more information when you need to prepare for further in the future.
And the homepage widget gives a quick overview of what locations are open now, and when they’ll close for the day.
Did we mention they all look good on our mobile site too? (Phew.)
Easter egg: Hours on Google
Our user research highlighted Google as a popular tool for checking hours. Unfortunately, while Google’s crawlers did not pull the correct hours from our website for a long time, we were not manually updating the information either. Turned out we can’t blame our users for going to the library’s doors to check the hours!
The team finally made this right through this project. The library’s Website Steering Group worked with Access & Information Services and figured out a plan to keep the business information on Google up-to-date. Now if you just need the public hours, you can trust Google as well!
Update February 2021: Check out the design assets of this project in Figma Community. Feel free to duplicate, modify, and use for any of your projects! See how Indiana University Libraries implemented this design on their website: https://libraries.indiana.edu/hours.
