Who was involved in your partnership work, and how did everyone become involved?
Over the course of a year, we collaborated with 80 students from various subject areas and levels of study. All these students were recruited via the Bodleian’s 21-22 Student Panel, a group of students who had volunteered to be sent opportunities to give feedback and work in partnership with Bodleian staff over the 2021-22 academic year.
We initially recruited students to join this panel at the 2021 Freshers’ Fair. At our fair table, students could choose to provide their email to enter a prize draw for a £100 voucher or a Bodleian ‘keep cup’. We then invited students who entered the prize draw, via a single email, to sign up to the student panel and provide details about their course of study. Over 2,000 individuals entered the prize draw, and about 450 students signed up to the 21-22 Student Panel.
For all the activities that we invite students to participate in, including this activity, we thank students were with various forms of recognition, from National Book Tokens to VIP privileges such as exclusive views of the special collections and special access to the balcony of the Weston Library.
What did you set out to achieve in your student-staff partnership work?
We aimed to decide how to configure and adapt SOLO as we were migrating it to a new digital platform, as part of a larger digital migration project.
When and where did you work together?
We worked with students through a series of 1-hour Microsoft Teams meetings between August 2022 and August 2023.
How did you work in partnership?
To determine how to adapt SOLO to meet students' needs within the constraints of the new digital platform, we engaged with students in a collaborative and iterative process of usability testing.
There were four rounds of testing, each involving 20 students. For each round:
- Setting the scene: Each student who took part in the process met 1-1 with a staff member over Microsoft Teams. The staff member began the session by explaining:
- the changes that had already been made to the system as a result of previous testing rounds,
- where we were in the overall change process, and
- our hopes to work with the student to come up with additional changes that we could propose to our IT team.
- Usability testing: Students then shared their screens and performed tasks related to their studies. These tasks were designed to simulate common scenarios, such as using a reading list or following up on a list of references from a journal article. As students carried out these tasks, we encouraged them to vocalize their thoughts, intentions, and frustrations as they navigated through the system.
- Brainstorming changes: We then discussed with students what ‘blue sky’ changes they would make to the system. We were honest about what might be out of scope and worked with students to problem-solve how we might get around these barriers to change.
- Making changes: We then brought all the proposed changes from our conversations with students to our IT team, who sought out ways to implement our suggestions wherever possible.
- Recognising students: At the conclusion of each testing round, we sent an email to all the students who worked with us to acknowledge their contribution to the project and, if relevant, why any changes that we (as student-staff partners) had put forward to the IT team couldn’t be made.
We then repeated this cycle with all the changes from this cycle having been made. Due to this iterative nature of working with students, we were able to find out about the unintended consequences of the changes we had made in the previous round, which ensured the system evolved in a way that closely aligned with students' needs and preferences.
What did you learn from working in partnership?
The partnership approach we took between students and staff in shaping the SOLO system enabled us to gain jaw-dropping insights that we had previously never thought to consider. As a result, we were able to make beneficial changes that had not been on the cards with just the feedback we had received from students on the previous SOLO system. For example, we learned how students would prefer to be able to navigate the system, in terms of seeing which libraries and books are available to them. Without working so closely with students to brainstorm proposals to put forward to the IT team, we doubt those preferences would have been accounted for in the new SOLO configuration.
Although this approach to shaping SOLO involved fewer students than we may have been able to engage via a survey, it was significantly more valuable and impactful student engagement. Being able to work with students to brainstorm changes to the system meant that we were able to design a system that aligned with students’ needs. We never needed to guess how to respond to student feedback.
What advice would you give to other students and staff who may wish to take a similar student-staff partnership approach?
We feel it was important that we brought students in at a point where they had a real system with real limitations to work with. Had we brought in students before the system existed, there wouldn’t have been enough practical constraints to ground our work in the reality of what was possible. This reality enabled us to communicate what we were working with and then work in partnership with students to make tangible decisions. Had we brought students in earlier, we likely would have only been able to collect their ideas only to find out that they weren’t possible down the line—an approach that would have degraded students’ feelings that we cared about their inputs.
