Reading Lists: finding out what users really want

By Elizabeth Simpson and Kirsty Whitehead

In summer 2016 it was decided that the Library would look to upgrade its reading list system. The in-house system we had developed was at the end of its life and we wanted to switch to a product provided by a commercial provider. Members of the Academic Liaison team were on the project group and their primary responsibility was to engage our university community in the process of selecting the new system.

Gathering user requirements

We were fortunate to be able to pull feedback from a variety of sources. In addition to the knowledge that we already have through our work with academic departments, we were able to draw on existing feedback from our subject emails, CRM, and most importantly, the Understanding Academics project that had recently started. Rather than going back out and asking people to comment again, we started by synthesising the rich commentary we already had. The aim was to be able to clearly articulate what features people would like to see in the new reading list system. 

What did we do?

Initial work had already been done to code up the Understanding Academics interviews. During the summer of 2016 we looked at the 30+ pages of comments related to reading lists, and the first step we took was to analyse the comments in more detail and identify the main themes that emerged. We also made a note of our initial thoughts and ideas about how we could take this forward, and created a summary of them. Below is a snapshot of the document:

1.

Theme	Number of comments	Summary of comments	Take forward....
Alternatives to EARL	1	Currently using paperpile to generate lists
Clunky	20	Needs to be more user friendly for staff and student users. Issues raised: multiple screens, slowness, too many clicks, it’s ugly, difficulty moving items within lists and between lists (esp if scans are attached), only works properly with IE. rolling over could be smoother or automatic should be able to hide specific items for future use. difficulty finding items which are already in stock	Invite staff/student reps to the supplier demos. make it easier for staff to input the details of the item(s) they want to include (importing/bookmarklet) esp. for items on the catalogue. provide more flexibility for editing lists make it easier to find items already in the catalogue? improve rollover (automatic if possible)

However, this didn’t provide clear enough criteria that we could use further on in the project in terms of assessing potential systems. We developed a second document that really drilled down and listed each requirement separately, stating the needs and goals of our academic staff and students. Below is a snapshot of the document, in total there were 39 requirements listed. This was also useful to share with other colleagues in the project team who came from Collections and the Electronic Learning Development Team (ELDT) team.

2.

Id	Epic Category	As	I Want....(to do)	So That (Goal)...	Would Like to Have	Type	HL Acceptance Criteria
REQ-001	EPIC-001 Create a new reading list	Academic staff	Import references from a list I have already created e.g. word, paperpile, google doc, Endnote or other reference management software i.e. batch import.	I don't have to spend hours/days to create the list in a new piece of software. And it is easy to include things that I know we already have in stock.	Must Have	Interface	Must be able to import files from a variety of locations in a variety of formats (eg RIS). Must be able to identify resources which are in stock from imported list, and automatically create links to these on reading list.
REQ-002	EPIC-001 Create a new reading list	Academic staff	Import a list of references from our library catalogue e.g. list of starred items, rather than having to type everything into EARL individually and hope I've included the right information to find the item I want.	I don't have to spend hours/days to create the list in a new piece of software. And it is easy to include things that I know we already have in stock.	Must Have	Interface	Must be able to import files from a variety of locations in a variety of formats eg RIS. Must be able to identify resources which are in stock from imported list, and automatically create links to these on reading list.

How did this feed into the selection process? We decided that we needed to involve academic staff and also students in the process of selecting a reading list system. Using the feedback we had gathered via the process above and also from our conversations with other institutions, we devised 3 scenarios for the invited suppliers. These 3 scenarios covered all the points from the user requirements spreadsheet.
Five people from the project team were the official scorers but the staff and students who attended were also given a scorecard with which to score the scenarios, and prompts were provided. There was also space for them to write any other further comments. The feedback from the university community was to act as a benchmark should we all have wildly different scores. As it happened, we all scored the suppliers in a very similar manner.

"What does EARL* even mean?” This was one of the comments about our old system (called EARL) from one of the Understanding Academics interviews. We used switching to the new system as a chance to update the name and simply call the system Reading Lists. This has elicited lots of positive feedback from academic staff and students, who refer to lists as ‘reading lists’ and were often confused by our use of ‘resource’ lists. The new name reflects this user preference, regardless of the fact that lists contain much more than just reading.
What’s next? 18 months later, as part of reflecting on how successful the project has been, we’ve been able to return to the user requirements spreadsheet and evaluate the system that we have now. Having looked at each requirement individually, 91% of them have been met either partially, fully or, in some cases, requirements have been exceeded. The few requirements which haven’t been met relate to referencing styles, which is work in progress, and restrictions in the library catalogue system. After a really busy few months combining the start of term and the switch to the new system, being able to go back to the user requirements spreadsheet and use this to evaluate the work that’s been done has been invaluable, especially in helping us to plan our next steps.

Indeed, the work that we’re doing around this shouldn’t stop now that the system is fully up and running. We need to sustain a dialogue with users of the system in order to remain aware of their experiences of using Reading Lists: what they like and don’t like about it, and how this should shape proposed developments in the system.

For instance, in November we ran a focus group to which we invited staff and students from all departments. We felt it was timely to do this since we had reached the end of Reading Lists’ first term, and it seemed a good way to keep the conversation open with the academic community who had been so engaged with the process right from the start. The session allowed to us to gather some useful feedback about how people are using the system, and most of it was very positive, and it also gave us the chance to talk to people about the proposed changes that we want to make to Reading Lists. We will continue to run regular focus groups so that we can continue this conversation, and we are also continually collecting feedback that we receive during Boards of Studies in our departments, anecdotally from staff and students and via the training sessions that we provide. One of the great things about having a new system means that we can finally be more responsive to the concerns that our user community have and we are keen to ensure that we continue to actively engage with them.
*Easy Access to Resource Lists

Understanding Academics UX project

By Vanya Gallimore, Acting Head of Relationship Management

We wrote about our PGRUX project all the way back in July and mentioned that we hoped to post soon about our most recent project, Understanding Academics.

It’s rather an ambitious sounding title and indeed lots of academics laughed when we mentioned what we’d called it and wished us good luck! What we wanted to achieve in this project was to really gain a better understanding about how our academic colleagues approach their teaching and their research and where we, the library and the services we provide, fit in with that. It would also give us the opportunity to look for new services that we could potentially be offering and/or problems with our current services. We also hoped it would give us a greater understanding of how each academic department works within the University so we can start to provide tailored support for departments. Finally we hoped it would allow us to nuance our communications and think about how best we could talk to departments.

Background to the Project

The creation of our academic liaison team in 2014 strengthened our relationships between the Library and the departments but we wanted to build on that and go deeper into understanding the needs of the academic community and ensure that those needs were reflected into our service developments.

The work was intended to inform a variety of projects and pieces of work which are due to be undertaken over the next year in Information Services. This includes but is not limited to the following:

• Understanding textbooks
• Replacement for our inhouse reading list system and associated processes and procedures (Key text collection)
• York Pedagogy (and associated digital literacy teaching)
• Our lending system
• Student and staff inductions
• Communications to departments
• Engagement with those not based at our main campus, Campus West
• Buying habits of departments and individuals of resources
• Research Support services
• Understanding, managing and promoting our collections

We agreed, after much discussion and an earlier ambitious target, the aim of interviewing 4 members of staff in each academic department, ideally two focused on teaching and two on research (note: we didn’t mind if people had joint roles - rarely do people only do one of these activities - but we wanted them to concentrate on just one area for the purposes of the study as we had limited time with each individual and a lot to cover during that time).

We trialled the technique with three friendly academics to ensure that it worked, we had allowed enough time and to get their feedback on the process. These initial interviews worked really well and allowed the process to be refined before starting to undertake them across all departments.

Ethnographic methods

The project involved two UX techniques: a cognitive map, followed by a semi structured interview. While we had used love/break up letters in the PGRUX project we decided against using these for this project. We did find that some academics were very sceptical about the cognitive maps and didn’t fully understand what the point of it was but in nearly all cases they were pleasantly surprised by how useful they found it afterwards.

We did not offer any incentive for taking part and in some departments we had academics actively volunteering to be interviewed. I think this was due in part to how we pitched it about wanting to know more about them, rather than asking a series of questions about the library. The two questions we started with were very broad (can you draw a map of your research process or how you approach a new or existing module for teaching) to understand how the academics worked and where we, the Library, could see ourselves fitting into their process (were there missed opportunities, things we were doing they didn’t need/want etc).

The semi-structured interview always started with asking the academic to talk through their cognitive map with us and taking things from there. As much as possible we were led by the academic as we wanted to understand what was important to them.  We did have some prompt areas for the semi-structured interviews if the academics didn't mention them at all e.g. reading lists, student skills, resources, dissemination of their research that we would ask about if there was time. Our aim was to ask open questions and not lead anyone (this was one of the big challenges, particularly in the first couple of interviews) and to ask "why" a lot.

Staffing the project

In order to ensure that we could undertake the volume of interviews we were expecting to have (about 110 - each just over an hour long, plus time to write them up etc.) we needed a large enough pool of staff.

For the two previous UX projects we had used an intern but we were really keen this time that we used our own staff for this. There were a couple of reasons: our staff have the contextual knowledge about the library and a student often won’t understand the library context e.g. things like metrics would be very confusing to them - we had researchers talk about their "H index" for instance. I also felt strongly that this kind of activity would give staff a better understanding of their own academic departments (and indeed a couple of the liaison librarians had already undertaken similar conversations with some departments that they could then build on). Finally this is the kind of activity that we want to do more of and if we don't develop our staff and are always getting in others to do this, we don't build up expertise in this area.

We decided that our academic liaison librarians were best placed to undertake this work and in order to ensure that they had the necessary skills and confidence to do this, we put together a four week training programme for them. This consisted of:

• An overview of the UX techniques to be used and time to practice these on each other
• Neuro linguistic programming (NLP) training
• Business analysis tools (including techniques like the 5 whys)
• Active listening and questioning techniques

All except NLP were run by members of Information Services.

Due to the timing of the project we also had the opportunity to discuss the project during the Action Plan meetings with the Library Rep and Head of Department (HoD). This was really useful and we received a lot of support for the project at these meetings. HoDs were also useful in helping to identify individuals who would be good to take part, for example, new or relatively junior staff, research or teaching focused staff or someone they thought would be interesting for another reason.

Processing the interviews

We didn't have time (or money) to do full transcriptions of the interviews for this project so each interview was written up either in full notes or part transcription (where the academic talked through their cognitive map). This was then all coded into NVivo by a member of staff who and then produced reports on each "theme". These themes are now being analysed by a member of the team who will decide the best way to present the information e.g. the data about reading lists is helping to produce a list of requirements for a new reading list system but data around how researchers collaborate will help us to build personas about what researchers do/look like (or at least we hope it will).

One of the big reasons for undertaking this work in the first place was really to gain a better understanding about how academics work - both in their teaching and their research and to understand where we fit (or can fit) into that. We think librarians are often guilty of thinking we're the most important people and can't understand why someone hasn't got back to us. Understanding the other pressures that academics are often under is really useful (and helpful to articulate this to colleagues in other areas e.g. Collections) about why the deadline for reading lists is not working etc.

We now have a huge dataset and we need to continue to analyse each themed area. We will be updating the blog periodically as each area is reported on and we decide what to do with it over the coming year.