The User Experience of Logging In: An Introduction

I’m trying to work through some ideas pinging around in my brain about how to improve the user experience of logging in to library services and resources at a college or university. I’ve been thinking of a series of posts to help me pull together a bunch of ideas, insights, and quandaries around the problems users encounter as they try to access library stuff online. I’m hoping this initial post will get me started in writing all the posts I have in mind.

As much as possible, I’m trying to develop a wide perspective on the problem. As someone who does UX research and UX design at my library, I’ve found it essential to understand all the systems at play before trying to do any design work. If I don’t have a moderately informed understanding of how our services and resources interconnect with each other and with the ICTs (information and communication technologies) that our users are working with, my design efforts may miss some key component. In other words, the more you know about the systems and services, the better your designs can be. And I’d argue that every single thing we in libraries design must be perpetually improved and tweaked. No design is perfect. Furthermore, not only is technology ever changing, but society’s values and norms that affect our use of those ICTs are also evolving regularly in a socio-technical system of mutual shaping.

As someone who also helps manage e-resources and does troubleshooting at least several times a week to help someone who is reporting that they “can’t log in” to something, I’ve built up some standard questions to ask the user. I may not be a master of all the technologies at work behind the scenes, but I’ve learned enough to make reasonable guesses about what has gone wrong and ask the user questions that help narrow down the list of possible causes. This post is my attempt to categorize the places where problems arise and detail some specific issues: the status of the user, the user’s device, the library’s systems and resources, and a vendor’s systems or resources.

The Status of the User

Many access problems are connected to who the user is and what their status is at the moment the problem occurred. At a college campus like mine, someone’s status may evolve over time, as in the case of a student who just graduated and is now an alum. Here are other statuses that may be preventing access:

  • A student who is registered but classes haven’t started yet
  • A student who is taking a semester off
  • A student enrolled elsewhere who is only taking one class
  • A student in a continuing education program, not the degree programs at the school and not in one of the certificate-bearing continuing ed programs
  • A student who just graduated and is within the window where they still have student access
  • A student who graduated and now officially has alumni status
  • A staff or faculty member who has been hired but not fully set up with network credentials at the school
  • A staff or faculty member who just retired
  • A “friend of the library” or local community user who may have limited access privileges

The User’s Device

By device, I am thinking not just of the computer, phone, or tablet they are using but also the way they are connected to the internet. Some of the problems that arise in this area can be caused by:

  • A browser that is out-of-date
  • A recently updated browser that is creating previously unknown conflicts due to new security features
  • A browser that isn’t compatible with the resource or service the user is trying to connect to
  • Browser plugins or extensions
  • Security settings in the browser or device
  • Security software installed on the device
  • Network settings on the device
  • Settings on the network itself (e.g., ports that have been closed, firewalls, etc.)
  • A weak network or one that goes in and out
  • VPN software that needs to be updated
  • Cached files in the browser from previous sessions with that service or resource

The Library’s Services and Systems

In many cases, the problem a user reports is caused by a system or service that the library is entirely or mostly responsible for. When I say “library,” I’m including the larger institution that the library is a part of; for example, while a college library typically has no control over what ports on the network campus IT has shut off, someone in the library has to be aware of this and able to work with IT when a problem seems to be connected to that. Below is a representative list of the kinds of things that the library has some or full responsibility and that may relate to login problems:

  • A key part of the library’s or campus user authentication system (e.g., EZproxy, Shibboleth, active directory, etc.) is down or malfunctioning
  • Campus IP addresses have changed but the library wasn’t notified
  • The campus VPN service is down
  • Subscription problems (the vendor has cut off access unexpectedly due to a payment issue, although some of these problems start with misunderstandings or overly punitive responses by the vendor)
  • The library and/or the campus provide the user with a bewildering variety of login credentials for various systems, services, and resources
  • The login system we control (such as EZproxy) doesn’t provide the user with enough information about which login credentials are needed and how to get help when the user isn’t sure or is mistaken about those credentials
  • The library has fallen behind in work to keep e-resource holdings up to date (e.g., a database subscription that has been cancelled still has its holdings listed as active in the catalog or library services platform)
  • The settings in the proxy server for a specific resource (e.g., a database) are out-of-date
  • The resource is only available to a subset of the campus community or has a limited number of simultaneous users but the library hasn’t adequately indicated that on its website, catalog, library services platform, etc.
  • A e-reserves collection for a class from a previous semester.

The Vendor’s Systems or Resources

Probably the biggest frustration for libraries regarding the login problem is that we have a limited ability to effect changes in the systems we buy or license. While we may be able to do a reasonable amount of configuration of a library services platform that is hosted on the vendor’s network, there’s not much we can do about the ScienceDirect interface short of complaining through various official and unofficial channels or threaten to cancel when the situation becomes dire (frustrated users avoid the resource, which leads to low usage stats, which then makes the resource a contender for cancellation when its up for a renewal decision). The most common login problems users report are:

  • The resource requires the user to create their own set of login credentials but the interface doesn’t make that clear enough to the user the first time they encounter it or on later visits when they’ve forgotten this to be the case.
  • Although a campus-provided set of login credentials is required to get to the resource initially, once in, the user is encouraged to create a personal login (so they can save results, personalize the interface, etc.)
  • The user has found content in the resource that isn’t part of the library’s license (this is very much a design problem that could be solved by vendors if they cared enough about it).
  • The user has gone directly to the resource via links or a web search (you could argue that this is the fault of the user, but I’d say it’s the fault of vendors who have yet to recognize this very old problem and design WAYF [where are you from] functionality in the interface that can guide unrecognized users back to their campus login systems).
  • The vendor’s system is down.
  • The vendor has changed the URLs for a resource but hasn’t notified the library or the vendor for the library services platform (or the library services platform vendor hasn’t gotten to changing those URLs yet).
  • The vendor has rolled out a new platform that no longer works with your library’s current proxy settings.

What’s Next in This Blog Post Series

I’ve been working various efforts to improve the user experience of logging in at my library but I have a long way to go (and will never be done, as change in our systems, users, and society is eternal). One of the things that helps me come with design ideas is looking around on the web for inspiration. I’ll probably share some of what I found recently and how I might be able to borrow or build on designs (small and large) that others have put in place.

Other Posts in This Series

“The Contextual Nature of Logging In,” 22 February 2021.

3 thoughts on “The User Experience of Logging In: An Introduction

  1. As a retired high school and reference librarian, this thorough account of login experiences and issues took me back to my reference desk days. I recently read an article that highlighted how librarians who do their work well are often invisible to the public. Most library users are unaware that librarians are (at minimum) Masters-prepared professionals with a bank of knowledge that allows users a relatively seamless UX in their quest for information. This article details the knowledge and understanding required for one of the many responsibilities that present issues for librarians to manage or confront and solve on a daily basis.

  2. First time i have seen any concern for any site about logging in. Amazing ty. Please consider eliminating the log in button that says SUBMIT. It causes a flash of fury but is the only entry word used on many many sites. How about ENTER or WELCOME or COME IN etc etc.? Yes it means to provide info as in ‘submitting data’ but it also means much more unpleasant things that most of those designing websites haven’t experienced Please consider this. l

  3. Pingback: POST: The User Experience of Logging In: An Introduction ← dh+lib

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.