The Springer Nature sites the Librarian channel, the Librarian  portal, and the Metadata downloader will be a family of efficient application tools and info sources.

Springer Nature and my role

Springer Nature (“SN”) is the world’s second largest academic publisher. We curate and promote research output in a wide range of subjects, as journal articles, books and databases.

Our main business model is to license published content to academic institutions and companies. Librarians (sometimes called information specialists) are responsible for finding, licensing, and making content available to patrons (students, researchers, and other colleagues).

Since 2017 I have been doing product design in a team that provide self-service tools to librarians. I also advice our marketing team on the librarian content they publish.

When I started at SN I felt a need to deeply understand librarians since I base my work on a human-centered philosophy,. How else would I be able to help them become better at what they do? Very little knowledge about librarians existed in the SN IT organization, so I used 50+ interviews, blogs, mailing lists (!), and conversations with my colleagues outside the IT department to understand libraries and librarians. I still learn new things every week.

Is it bad that our sites look so individual?

My colleague Jo, product manager in the team, had a thesis:

1. Some librarian tasks require the librarian to use several SN sites to get their work done.
2. Since the sites look completely differently the librarians feel disoriented.

I conducted 9 research sessions to investigate Jo’s thesis.

It turns out that Jo was correct in that some tasks require the librarian to travel across several sites. However, none of the librarians who managed to complete tasks that needed cross-site journeys seemed to be deterred by the difference in visual languages. Jennifer even said the following:

The birth of a vision

While the answer to our initial question was No, I got other insights from the research. Together with my existing knowledge, a new vision for our sites emerged.

Librarian channel, Librarian portal, and Metadata downloader are a family

The first part of the vision is about the connections between some of our sites.

Insight: Content, footer and main navigation

When trying to complete the tasks most focus was on the content of each “page”. Links in content would be followed if the information scent was “strong”.

The main navigation is of course also used to find the bigger areas of a site.

However, if no link was found in the content, the footer was often used to navigate to a place that might be correct – the word “librarian” has strong info scent.

What’s interesting here is that both in the footer and in content it’s completely OK to link to a different site. That’s an opportunity for us!

Insight: Tasks, roles, and persons in the library

Tasks can be mapped to roles in the library:

• The role Metadata Systems Specialist handles tasks like link resolver and ILS metadata updates.
• The role Outreach Librarian handles tasks like info literacy training and 1-on-1 consultations for patrons.
• Et cetera

However: some roles, most notably the role e-Resource Librarian, covers many of the tasks involved in licensing and administering content from us.

Also: some persons hold several roles, especially in smaller library organizations.

Insight: Anchoring

In my sessions with librarians, the tasks were performed one after the other. The SN web page that the librarian was on when the previous task ended was the one that was open in the browser when the new task started.

Most librarians started the new task by looking at the SN site they already had open, like for DeeAnn in the video.

The librarians who searched for an answer via Google usually only explored the SN site they first landed on.

My theory: The cognitive bias of Anchoring caused the librarian to behave like this.

Insight: Family and relatives

Three SN sites – the Librarian portal, the Metadata downloader and the Librarian channel – are so overlapping that I consider them to be a family of tools and information. Our support sites and the publishing platforms are also used by librarians to do their tasks.

The close relationship is extra true for e-resource Librarians and for persons with many roles.

Diagnosis: We should help librarians travel within the family

The 3 core sites do not do a good job of helping librarians travel between the sites. The sites don’t act as one family. This results in that librarians contact sales reps or customer service unnecessarily often, which is expensive for SN.

Intervention: Understand and reduce travel blockers

The sites already exist. Therefore we should now understand what stops persons from traveling between them. And then remove the blockers.

Activity: Understand blockers

Already the foundational research, presented above, gave us knowledge about what needs to change. Also, the portfolio/hub-and-spoke approach – that SN has separate sites for separate tasks and/or audiences – will not change.

Solution 1: Give the family a hub

We need to create a hub for the tools. This hub will:

• Guide librarians to the different tools they might need for their current task
• Be a place to “go back to” when the current site does not offer the tool/info the librarian needs

Thus, the hub links to all librarian tools. And all the tools link to the Hub.

Solution 2: Use content to create connections

For tasks that cross site boundaries, and related tasks, provide links within each site’s content to the other sites that support the task.

Tools and info for librarians need to be efficient

The second part of the vision is about how librarians work with the resources we provide.

Insight: “I would contact customer service”

My team was founded to provide self-service tools for librarians. Several librarians I have spoken to appreciate the possibility of doing things themselves, on their own time, instead of relying on publisher staff.

In the sessions where I tested Jo’s thesis, the librarians were asked to perform tasks such as:

• finding the phone number to their regional contact,
• fixing/reporting an access issue,
• understanding the impact of transfers on the library,
• et cetera

Most librarians either directly said that they would contact us via email to perform the task, or they tried to find the info/use the tool online but ended up using the contact us links if they did not find the info/tool quickly.

Insight: Very many publishers

The 50+ libraries I have spoken to license content from 20 to 400 publishers. Some tasks such as updates to access methods and usage data downloads needs to be done individually for each of these publishers.

Insight: Our tools are used quite seldom

Analytics data show us that most librarians use the Librarian portal and Metadata downloader between 1 and 12 times per year, with the majority using our tools less that 4 times per year.

Insight: Low effort

I love the autoload feature in SFX. It saves me so much time.

Sara C, librarian, US University

Note: The autoload feature that Sara mentioned makes the librarian stop to use our self-service tools, as it automates a step that is manual in our tool!

…delighting customers doesn’t build loyalty; reducing their effort—the work they must do to get their problem solved—does.

Dixon, Freeman & Toman

Diagnosis: The Librarian portal and Metadata downloader should be efficient

So far, our tools have not been designed explicitly for low effort. But, they need to be efficient, even with infrequent use.

Intervention: Discover and reduce inefficiencies

The Librarian Portal and Metadata Downloader already exist. Some new tool development is happening within them. Therefore we should now discover existing inefficiencies, and also discover the inefficiencies we create in new tools. And then reduce the inefficiencies :)

Solution 1: Usability tests

We have done, and will continue to do usability tests on all our tools. From them we know of several usability issues on the sites.

Solution 2: Principles

We will evaluate our tools against the UX principles we are creating specifically for our products. We will also evaluate our tools against industry best practices from sources such as Designing UX: Forms and Tog’s principles.

Solution 3: Metrics

By using the HEART framework I found two metrics that will help us make the tools lower effort:

Goal: Tasks are completed via self-service.
Signal: Rate of completion of tasks via our tools.
Metric: Few online service contacts after interaction with our tools.
Instrument: Google Analytics events for clicks from tools to the Help & Contact page.

Goal: Our tools are efficient parts of librarians’ processes.
Signal: Effort needed to use our tools.
Metric: Low customer effort score (CES) per tool.
Instrument: CES survey after a task is completed in one of our tools.

The Librarian portal and Metadata downloader are applications

The third, and final, part of the vision is about how the tools fit into the full flora of tools that librarians work in.

Insight: Our info and tools are one step in long processes

The Librarian portal and Metadata downloader are (almost) never
the only tool or information source needed for a librarian’s tasks. Instead, we help with one step in a process that include other tools, info sources, services and/or people.

Example tasks:

Task: Update IP address ranges to enable access to licensed content
Role: Access system specialist

1. Get info from network admins
2. Get admin site login details from ERM or Excel sheet
3. Check if platform offers self-service (Librarian portal)
4. Report new ranges via form or email (Librarian portal, SN.com)
5. Document that the platform has been contacted
6. Follow up with platforms as needed (our support sites)

Task: Calculate “return on investment” for journal licenses
Role: Usage analysis librarian

1. Download COUNTER data from publisher (Librarian portal)
2. Summarize data in Excel
3. Get price data from own repository
4. Combine price data and COUNTER data in Excel
5. Run macros on the resulting sheet
6. Compare ROI between journals and publishers

Task: Evaluate new journal
Role: Acquisition librarian

1. Get request from colleague
2. Find details on content and list price of journal (SN.com, nature.com)
3. Liaise with Subject librarian/Head of acquisitions
4. Get trial from publisher (SN.com)
5. Make recommendation to Subject librarian/Head of acquisition

Insight: Some other tools in the processes

• E-resource management
• Browser bookmarks
• Excel
• Google Spreadsheet
• Link resolver admin interfaces
• Cataloging interface
• Integrated library management system
• Lyrasis admin
• EDS config
• EZProxy usage analysis
• …

These are all either
Data management applications
or
Settings/Config applications
or
Usage analysis applications
or
Business processing applications

Opinion: We are like Google cloud platform, not like Medium

Librarian portal and Metadata downloader do
Data management
and
Settings/Config
and solutions currently being built will be a
Usage analysis application
and one of our tools is a
Business processing application

• 

• 

• 

• 

Diagnosis: The Librarian portal and Metadata downloader are applications

SNAP and the Metadata Downloader is a collection of tools – an application for the people involved in cataloging, metadata management, access management and usage analysis. However, these sites are not structured like applications – collections of tools. It looks and behaves more like an information source.

Intervention: Understand and create the application experience

Metadata downloader is a data management tool. Librarian portal has data management and settings/config tools. The tools already exist (and we know what we will build in the near future). Therefore we can look at the tools to understand what we need to change to make them more like applications. Then we should, piece by piece, make the tools more like applications.

Activity: Inventory

I and my colleague Felipe made an inventory of the building blocks that the Librarian portal and Metadata downloader are constructed with:

• Main navigation
• Supporting navigation (Help & Contact, etc)
• Data tables
• Forms
• …

We then looked at each building block to see if any of them need to change for us to transform the Metadata downloader and Librarian portal into an application. We found 4 building blocks that need to change.

Solution 1: Tables for on-screen data management

Tables that librarians can use to understand and edit from 1 to 3000 records.

Actions that they will need to be able to take on the tables:

• filter & sort
• add, edit, delete
• aggregation like sums, counts, …
• download (custom) sets of records

Solution 2: Progressive disclosure of help info

The tools should, by default, contain very exact terms.
Example: “TR_J1”

But, some librarians will need the definition of the terms.
Example: “Journal Requests (Excluding OA_Gold)”

And some librarians will need deep info about the terms.
Example: A link to the COUNTER 5 code of practice

Solution 3: Landscape layout

The tools should use the available screen real-estate. Most of our users have screens that are 1200–1900 pixels wide. Our views should use that width when it is available, while also being usable on 320 pixel wide screens.

Solution 4: Multi level, state aware navigation

The navigation needs to support:

1. Two levels of tools
   Example first level: Content + Access + Usage.
   Example second level: within Usage 4 diff tools, within Access 5 tools.
2. Switching between organizations without losing state
   Example: reporting date range for COUNTER reports
3. Showing tools based on the status of the current organization
   Example: corporations have fewer tools than universities
4. Showing public and private tools based on if the admin is logged in
   Example: Metadata downloader is public, COUNTER 4 is private
5. Link to the Hub

The Librarian channel, Librarian portal, and Metadata downloader will be a family of efficient application tools and info sources.