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

UXLibsIII: impressions of a novice

By Vanya Gallimore, Academic Liaison Team Manager

First time attending the UXLibs conference and it was, quite simply, phenomenal! I've heard so much about the previous conferences (everyone seems to come away completed exhausted and inspired) but I've never been able to attend myself until this summer. Turns out, it really is exhausting and inspiring...and so much more.

We've been busy doing UX activities at York for the last two years and have written various blog posts about our work. We've tried a range of techniques including love-break up letters, cognitive mapping and semi-structured interviews, but what struck me at the conference was how much more there is to learn and put into practice. People came to the conference with lots of new ideas and their experiences of what works (and sometimes what doesn't work, which is always interesting to hear too). The conference is hugely international, with the Scandinavians leading the way on a lot of UX innovation, and it was fascinating to learn more about the reach of UX in libraries across the globe.

There were some key take-home messages:

• The importance of being able to articulate what UX actually is in a succinct and meaningful way to get engagement from your institution: rich and deeper knowledge of user experience (Andy Priestner).
• UX works well when you get everyone involved, not just one or two individuals in an organisation. How can we democratise UX and truly empower teams?
• We need to understand that the services we offer in our libraries reflect our core values. When we build things, we want them to be expressions of US, of our values. Our expertise, our service ethic and our values remain our greatest strength.
• Ethical design matters hugely: how will the objects that you design affect your users? When we create products and services, we need to really care about who is actually going to be using those products and services.
• Never make assumptions about how your customers use your services!

And some things that we would definitely like to consider taking forward at York:

• UX meets information literacy: getting students to use capture technology to record themselves using the library catalogue to find resources for a specific assignment. They don't use the catalogue in the way that you expect them to - at all!
• Idea originally from Manchester: "If students did libraries..." what changes would they make to improve the library experience?
• Visitor and resident mapping exercise to understand use of, and engagement with, digital tools.
• Design Think: how can we introduce new design thinking methodologies into our planning processes and practices?
• Creating effective personas that take the data about our users, humanise it and communicate patterns of behaviour to other people, while still reflecting the complexity of users.

So, there is a lot to think about and trial out over the coming year, and I'm really excited about the ongoing opportunities that UX presents to really understand and improve the user experience for all our users at York.

For my part, I gave a presentation about the Understanding Academics project that we have been doing over the past eighteen months, focussing on how we managed all the data associated with such a large-scale project. We're nearing the end of that project and will be posting our final conclusions and next steps shortly. It's just one of many, many UX projects taking place globally and I'm grateful to UXLibs for bringing some of these together and allowing us all to learn from each other. Here's to UXLibs IV...

Maximising impact: scaling-up UX activities (and how to manage all that data!) from Vanya Gallimore

Processing and ACTING ON 100+ hours of ethnography: a 5 stage approach

By Ned Potter, Academic Liaison Librarian 

Understanding Academics, introduced in the last blog post, is far and away the biggest UX project we’ve attempted at York, and the processing and analysis of the data has been very different to our previous ethnographic studies. This is due to a number of factors: primarily the sheer size of the study (over 100 hours’ worth of interviews), the subject matter (in depth and open ended conversations with academics with far ranging implications for our library services), and actually the results themselves (we suspected they’d be interesting, but initial analysis showed they were SO insightful we needed to absolutely make the most of the opportunity).  

Whereas for example the first UX project we ran conformed almost exactly to the expected 4:1 ratio of processing to study – in other words for every 1 hour of ethnography it took four hours to analyse and process – the total time spent on Understanding Academics will comfortably be in excess of 400 hours, and in fact has probably exceeded that already.

UX is an umbrella term which has come to mean a multi-stage process – first the ethnography to understand the users, then the design to change how the library works based on what you learned. In order to ensure we don’t drown in the ethnographic data from this project and never get as far as turning it into ‘proper’ UX with recommendations and changes, Michelle Blake and Vanya Gallimore came up with a 5 stage method of delivering the project.

Two particular aspects of this I think are really useful, and not things we’ve done in our two previous UX projects: one is assigning themes to specific teams or individuals to create recommendations from, and the other is producing and publicising recommendations as soon as possible rather than waiting until the end of the whole project.

As you can imagine the 5 stage method is very detailed but here’s a summary:

Coloured pens used in cognitive mapping
(in this case with the interviewer's reminder about the order
in which to use them)

      1)  Conduct and write up the ethnography. Academic Liaison Librarians (ALLs) spoke to around 4 academics from each of ‘their’ Departments, usually asking the subject to draw a cognitive map relating to their working practice,
and then conducting a semi-structured interview based on the results.

The ALLs then wrote up their notes from the interviews, if necessary referring to the audio (all interviews were recorded) to transcribe sections where the notes written during the process didn’t adequately capture what was said. The interviews happened over a 2 month period, with a further month to complete the writing up.

      2)   Initial coding and analysis. A member of the Teaching and Learning Team (also based in the library) who has a PhD and experience of large research projects then conducted initial analysis of the entire body of 100+ interviews, using NVIVO software. The idea here was to look for trends and themes within the interviews. The theming was done based on the data, rather than pre-existing categories – a template was refined based on an initial body of analysis. In the end, 23 over-arching themes emerged – for example Teaching, Digital Tools and Social Media Use, Collaborations, Research, Working Spaces. This process took around 2 months.

      3)   Assigning of themes for further analysis and recommendations. Vanya then took all of the themes and assigned them (and their related data) to members of the Relationship Management Team – this consists of the Academic Liaison and Teaching and Learning teams already mentioned, and the Research Support team. This is the stage we are at now with the project – each of us in the team have been assigned one or more theme and will be doing further analysis at various times over the next 8 to 10 months based on our other commitments. A Gantt chart has been produced of who is analysing what, and when. The preparation and assigning of themes took around 2 weeks.

      4)   Outcomes and recommendations. There are three primary aims here. To come up with a set of practical recommendations for each of the themes of the project, which are then taken forward and implemented across the library. To come up with an evidence-base synthesis of what it means to be an academic at the University of York: a summary of how academics go about research and teaching, and what their key motivations, frustrations and aspirations are. (From this we’ll also aim to create personas to help articulate life for academics at York.) And finally to provide Information Services staff with access to data and comments on several areas in order to help inform their work – for example members of the Research Support team will have access to wealth of views on how academics think about Open Access or the repository.

These aims will be achieved with a combination of devolved analysis assigned to different groups, and top-down analysis of the everything by one individual. Due to other projects happening with the teams involved, this stage will take up to 7 months, although results will emerge sooner than that, which leads us neatly to...

      5)  Distribution and Dissemination. Although this is last on the list, we’re aiming to do it as swiftly as possible and where appropriate we’ll publicise results before the end of the project, so stages 4 and 5 will run simultaneously at times. The total duration from the first interview to the final report will be around 18 months, but we don’t want to wait that long to start making changes and to start telling people what we’ve learned. So, once an evidence-based recommendation has been fully realised, we’ll attempt to design the change and make it happen, and tell people what we’re doing - and in fact the hope is to have a lot of this work completed by Christmas (half a year or so before the Summer 2017 intended end date for the final report). 

The full methods of dissemination are yet to decided, because it’s such a massive project and has (at a minimum) three interested audiences: York’s academic community, the rest of Information Services here, and the UX Community in Libraries more widely. We know there will be a final report of some sort, but are trying to ensure people aren’t left wading through a giant tome in order to learn about what we’ve changed. We do know that we want to use face to face briefings where possible (for example to the central University Learning and Teaching Forum), and that we’ll feedback to the 100 or so academics involved in the study before we feedback to the community more widely.

As we go through this project we’ll try and keep writing on this blog to update on where we are, what’s working, and what the challenges are. Above all, Understanding Academics has been one of the most exciting and insightful projects any of us have ever attempted in a library context. 

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.