More Thoughts on Language Usage and Design

Building on what I wrote about in yesterday’s post, “Watching the Language Parade of Our Users,” I want to add some miscellaneous thoughts I’ve had since that complicate the stance I took about the need to pay attention to what words our students and faculty use (especially the ones that relate to tasks that might bring them to the library website). One of the words that I mentioned in yesterday’s post, “loan,” is notable mostly because students sometimes use it in a way that I’d consider incorrect. When a student says that they’d like to “loan something from the library” or that they have “loaned a book and want to know how to return it,” I understand of course that they really mean “borrow.” I suspect that if I were to correct a student in person (and they weren’t too annoyed with me for doing that), they’d quickly recognize their error. Typically, when I hear a student make a mistake like that in a reference or classroom interaction, I try to gently introduce the correct usage without being overly obnoxious or direct about it (“If you’ve borrowed a book and want to return it, here is how to do it.”)

When it comes to writing for the website, there’s often (but not always) an opportunity to write in a way that discretely introduces users to jargon and usage that is essential or useful. But when you’ve got a button or link you need to add a label to, your options are more limited. You’ve got to choose just one word or phrase that fits in the allotted space, is likely to be meaningful to the least sophisticated user but still recognizable to the most advanced one, and that strikes the conversational tone that you aim for in all your writing for the site. The challenge with language, though, is that it is ever evolving, and your choice today for that button may not work too many years down the road.

The word “rent” offers a notable challenge for library websites. Increasingly, I hear students say they’d like to “rent a book,” a phrase that I still find jarring. I also find it a bit upsetting, too, because to my ear it connotes a commercial interaction even though our borrowing services are free (unless you want to get technical and figure on how tuition and taxes figure into the cost to the user of borrowing books). I think it’s safe to assume that most (if not all) of our students get that there is no cost to borrow books, and yet they increasingly use a term that carries the whiff of money being exchanged. At what point will I need to seriously consider using the word “rent” in some way on the website? How common a usage does it have to become before I give in? I don’t have an answer, but I do think I need sit with these usage questions and not forget about them.

I should note that well before I transitioned from being a reference and instruction librarian to a UX librarian in 2010, I was fascinated by “Library Terms That Users Understand,” a website maintained by a librarian, John Kupersmith, who was formerly at UC Berkeley. Kupersmith’s site reviewed usability studies that answered questions about terminology and labeling and then tried to boil down the findings to best practices. Although the site is long gone, much of the content can be found in the eScholarship repository at UC Berkeley.

I’d like to mention two other sources that notably deepened my appreciation for the importance of user-centered language. First, a classic UX book by Steve Krug has a title that says it all: Don’t Make Me Think. Users are often task-driven, and if they have to pause too long to figure out what an ambiguously worded label or link means on a site, their satisfaction with that site starts to dip, sometimes precipitously. The other source is a terrific blog post from 2013 by librarian Barbara Fister, “Tacit Knowledge and the Student Researcher,” which “identifies the tacit knowledge many of us [librarians and faculty] have about information and how it works based on experiences that our students haven’t had.” Although the post isn’t directly about language use, it speaks to a familiarity with concepts that we can’t assume all of our users have; for me, learning to recognize these mistaken assumptions about what students already know helps me keep in check my tendency to fall back on library jargon when writing for the web.

One idea I’d like to learn more about and apply to my work as a UX librarian are “mental models” and how those may guide interactions users have with our site as they work on a task. There’s a rich literature in the social sciences about mental models that I need to dip into. I’m thinking it also connects up with the research being done by librarians into the issue of “container collapse,” as a student who doesn’t even know what a scholarly source is and how it can be recognized in part by the container it comes in will have a hard time navigating our websites when they’ve got a task assigned by a professor to find scholarly sources for their research paper. As we design for our websites things like custom search boxes, research guides, help documentation, instruction videos, etc., our work can be strengthened if we have a deeper appreciation for how our students understand the information landscape and what terms they are currently using to label its landmarks.

Watching the Language Parade of Our Users

As a former book editor whose wife is a freelance proofreader and copyeditor, I have to work hard to stifle my inner prescriptivist when it comes to language usage. As a UX librarian, though, I have to pay attention to the language our students and faculty use at my college and respect it as much as is possible if I hope to make sure that our site and services align with the way our users speak. Back in 2017, I was struck by this great quote by John McWhorter, a professor of linguistics at Columbia University, from an interview of him on an episode of the ever fascinating podcast, Hidden Brain:

Language is a parade, and nobody sits at a parade wishing that everybody would stand still. If the language stayed the way it was, it would be like a pressed flower in a book, or as I say I think it would be like some inflatable doll rather than a person. I think that it’s better to think of language as a parade that either you’re watching or, frankly, that you’re in, especially because the people are never going to stand still. It’s never happened, it’s never going to. And if you can enjoy it as a parade instead of wondering why people keep walking instead of just sitting on chairs and blowing on their tubas and not moving, then you have more fun. I want everybody to have the fun I’m having.

For anyone who has struggled to tinker with language on a website, you know how hard it can be to balance the demands to be concise, clear, and understandable. As language shifts, we have to be ready to tweak the language we use so that we don’t confuse our users or otherwise put them off (“The library’s facsimile machine can be found next to our laser printers and our ready reference shelves.”)

Here in no particular order are some bits of usage that caught my attention when I first heard them and am wondering when I’ll be ready to use them in some fashion on our site.

  • “loan” used in a reversed manner, as in the student who says, “I loaned a book and was wondering when I have to turn it back in.”
  • “rent”, as in “Can I rent a book?”
  • “journal” used to actually mean “journal articles,” as in “I need to find a journal on how left-handed broccoli farmers have navigated changes in agricultural technology.”
  • “in stock,” as in “Do you have this book in stock?”
  • “search up,” as in “I was trying to search up a book in the catalog but could use some help.”
  • “the library website” used to refer to our discovery service or a database, as in “I was searching the library website for info on the marketing of electric cars in Japan but was having some trouble.”

Where are the Online LibUX Communities?

This is just a quick note to ping the library UX community to see where it is that most folks are gathering online to talk shop. If anyone can fill me in on the state of these communities and how viable they still are, I’d appreciate it greatly. As you will see in my quick review of the sites that I’m familiar with, I’ve got some preferences about spaces where I’d like to be a visitor and others where I’d rather be a resident (see David White’s work on the visitor and residents model for more on that concept).

Library UX on Slack

Home: https://libux.co/slack

Register: https://libux.herokuapp.com/

Until the pandemic set in last March, I used to be quite active here. It was a busy place at times, and then lately not so much. Among the online communities I’ve kept an eye on, this one was usually the busiest. One notable downside about it is that it’s a free Slack space, which means that only the last 10,000 messages can be viewed or searched.

#libux on Twitter

Home: https://twitter.com/hashtag/libux

Although I’ve been posting to Twitter since early 2007, almost all of that activity has been me sharing articles and blog posts that I’d saved in Instapaper and thought to be worth sharing (I’d set up an integration between the two services to auto-tweet any saved item that I’d favorited). Although I am more of a visitor in Twitter, I can envision becoming more of a resident there if the libux hashtag gets used more. There’s also a uxlibs hashtag, but that seems to be used mostly for the annual UXLibs conference in the UK that I’ve heard great things about since its launch.

UXers channel on code4lib Slack

Home: https://code4lib.slack.com/

Register https://code4lib.org/slack

Not a lot of traffic here in a while but it would seem (in theory at least) to benefit by being within the code4lib community, which has long been very lively in various online spaces. This is also a free Slack space, and so has limits on how far back you can view or search messages.

Library UX Community

Home: https://luxcommunity.web.illinois.edu/

Register: https://luxcommunity.web.illinois.edu/registration/

I’ve always been partial to the bulletin board style forum, which this WordPress site offers. It hasn’t had a lot of traction yet but holds promise.

The Contextual Nature of Logging In

In my previous post, I discussed how the status of the user may play a role in their inability to log in to a library resource or service. In this post, I’d like to dig deeper into the topic of how the actual experience for the user can vary depending on a complex set of factors. At the most superficial level of analysis of use, a person has a task that they are trying to complete. With the task of logging in to something, the user either completes the task or they don’t. Delving in the context of that ask is what I hope to explore here. My aim is consider the interplay between the practical aspects of the task and the mental state of users as they undertake the task.

This exploration seems important to me as part of my effort as a user experience librarian who works with a team of people to design, redesign, or simply maintain online library systems and services. A key principle for me in my work, and for anyone who is engaged user-centered design, is to cultivate a deep empathy for the user or, more to the point, users, in all their variety and complexity. At Baruch College, where I am a librarian, the core audience for our library website includes:

  • 19,740 students (80% are undergraduate students, 20% graduate students)1 that collectively speak 111 languages and represent 168 countries2
  • 493 full-time and 607 part-time faculty3
  • Administrators and staff
  • 4,000 students from the CUNY School of Professional Studies with 97% of them in fully online courses4 and their faculty

While our user base is clearly diverse, maybe more so than the average American college or university community, I’d argue that for any college or university there is a diversity of contexts of use that are also important to recognize during the design process. In the library environment, designers can develop that sense of empathy by drawing on insights gathered in many different ways, such as formal user research (usability testing, ethnographic field studies, focus groups, etc.) as well as from the countless interactions we have in reference settings and in the classroom. While I’ve learned quite a bit from user research and from reference and classroom settings over the years, I have to also mention the fascinating insights I’ve gained from fellow CUNY colleagues, Maura Smale at the New York City College of Technology and Mariana Regalado at Brooklyn College, who have conducted multiple ethnographic research projects to document the scholarly habits of undergraduate students at a handful of CUNY colleges.

Compounding the diversity of users that we have to design for, there are countless variables related to the context of the user’s task that are going to effect how successful any one of those users are when presented with a login page. All of these variables are considerations that a designer must be aware of and weigh in their mind as they make design decisions). In the remainder of this post, I’ll lay out each of these variables and unpack them.

What Is the Task That the User Is Trying To Accomplish

A user may encounter a login page from the library while engaged in a range of common tasks, such as:

  • Searching for a known item (for a specific article, book, video, etc.)
  • Searching by subject for sources on a topic they are interested in)
  • Checking he status of something they have borrowed or requested or would like to request (due dates, fines, delivery dates, study room availability, etc.)

Why Are They Doing That Particular Task

If you can envision the range of reasons why a user may be engaged with these common tasks, then you can be more responsive to user needs in your design efforts. A related question to why a user is trying to complete a task is how important that task is to them at that moment. The issue of importance of the task connects with how persistent a user may be with an effort to log in to something and be willing to find a solution when their login efforts failed. The importance of the task to them (its personal significance to the user) may determine just how frustrated they are when they’re unable to login. Consider the difference between users each trying to log into a database to find articles on a topic who have different reasons for trying to accomplish that task.

A student might heard that the library has such-and-such database and wants to see what kinds of things are in it. Or maybe the student is in a workshop led by a librarian who has been invited into the student’s classroom by the professor. It’s likely the frustration levels will be lower in these kinds of casual uses than in more high-stakes use scenarios, such as a student who is under a tight deadline to finish a research paper with only hours to go before their deadline or a student who is stressed about and somewhat bewildered as they are working on their first-ever research paper. It seems a reasonable assumption that a casual user will be less frustrated by a login page that is confusing or even a dead-end for them than a user who is working on a project that is very important to them or challenging to them.

How the user reacts to the challenge of a login page will be shaped to a certain extent by reason why their task has brought them to this point. It’s reasonable to assume that the higher the stakes the context of the task is, the more likely it is that the user’s stress will undercut their ability to solve the puzzle of how to get past the login page, a process that often requires the user to slow down and think carefully and with some persistence about what credentials are being asked for. In short, stress can short-circuit the user’s ability to successfully log in to something.

Where Is the User When They Are Trying to Login

Consider all the places a user might be when they are trying to log into something:

  • They are at home, which may be quiet or very busy and distracting
  • They are at work where their efforts to log in take place during a break or maybe they’re trying to sneak in some schoolwork
  • They are using public wifi in some location where they may be worried about how much time they can be there or they be working hard to tune out distractions around them
  • They are on the go (e.g, using a phone while riding in a car, bus, train, etc.)

In each location, there may be greater or lower levels of frustration or stress for the user as they work on a task that may in turn effect how successful they are when presented with login requests.

What Device and Network Is the User On

The size of the user’s screen, how well a site is designed for accessibility, and the available input tools (keyboards, touchscreens, touchpads, mice, styluses, etc.) can all dramatically effect the user’s experience on any website. When designing a set of login pages, the designer needs to consider the range of devices users might have and make sure their login system performs equally for all of them.

The expectations for what users think they can do easily on a device may not line up with reality. It might be, for example, the case that when the user on a phone has entered the wrong login credentials, the error messages that are then displayed don’t convey as clearly as on a big screen how to get help for this error (i.e., systems to confirm your credentials, to reset them, or link to chat, email, or phone help options). Even the input devices that the user’s device has may also be harder or easier to use for the text input boxes where the user name and password are entered (for me, I am much more prone to typing errors on mobile devices than on a full-sized keyboard, which is especially apparent when I’m typing in passwords that are filled with numbers, symbols, random letters that may be capitalized).

Another variable is whose device someone is using when trying to log into something. It’s fair to assume that a person’s comfort level when encountering login requests and their success rate in getting past them goes up when they are using their own device that they regularly use, one that may have user names and passwords stored already in the browser or a password manager. On a device not our own, we can’t count on having those stored login credentials readily at hand, and our overall comfort and skill level with that device is likely to be lower than when it’s own our device. If the device is one shared in a household, there may be increased pressure on the user to complete their tasks quickly so that others can have their turn to use the device (I’m thinking here of the way my two sons used to battle and bicker over the family desktop computer in our living room).

The network that a user is on is yet another factor. Think of all the possibilities and how they shape the user experience:

  • A strong broadband connection on your home network vs. a weak one at home that cuts out intermittently
  • A work network where you may be worried about your employer being alerted to what you’re doing on work time
  • A mobile network that cuts out as you are on the go

How Savvy Is the User with Managing Logins

Is the system the user relies to keep track of logins sufficient or a source of ongoing frustration for them? Do they have no system for this, do they rely on scraps of paper, a notebook, browser storage, or a password manager? Do they find themselves always having to use the “forgot your user name” or “forgot your password” features? Are they surprised and annoyed when their efforts to find sources for a paper are leading to logins? Can they recognize the difference between a login system that the library has set up from a login system from the vendor that will only work for individual subscribers to that service or database?

When designing login systems, we should be making systems that are intelligible and usable for the least experienced user and that are as forgiving as possible.

What’s Next

As I’m thinking aloud here in these blog posts about the UX of logging in, I hope to be working toward some recommendations about design options for login systems that take into consideration the variability of user experience of library systems and services. I’m hoping to remind myself of what I’ve learned over the years and, more importantly, to recognize what I know I don’t know. The first thing I want to design is a better help page for users at my library who are having trouble logging in to something that my library is responsible for. I’m also interested in exploring whether some sort of troubleshooting guide for users might be worth the effort. Before I get to that, though, I want to write a post about how one moves from recognizing and understanding all the contextual variability of logging in to deciding what use scenarios are the ones to focus on in design efforts. This is always a problematic issue, this leap from UX research to UX design that requires you to limit the number of problems you hope to solve. Knowing which problems matter the most is always the most difficult part of the process. Following that post, I want to look at what sorts of help pages and troubleshooting systems libraries and other institutions have designed to assist users with the login process. I also think I need to do a post on what I wish our vendors would do to help us make the login process easier and what things we in libraries can be doing now.

Notes

1 Baruch College, “Fact Sheet,” 2020.

2 Baruch College, “Facts at a Glance,” 2020.

3 Baruch College, “Baruch College Self Study 2020,” 2020.

4 CUNY School of Professional Studies, “About,” 2021.

Other Posts in This Series

“The User Experience of Logging In: An Introduction,” 29 January 2021

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.

Advice for UX Shops of One in Libraries

On Twitter recently, I was asked for advice about setting up a new one-person UX shop in a library. I’ve only recently emerged from the UX-shop-of-one world, thanks to the addition of a part-time UX designer to my “team” and am not entirely sure how much my experience yields universal insights. So consider the following caveats about how institutional differences will affect the usefulness of any thoughts I have about how to get started.
  • How many people work in your library? Size of the library staff matters. If you are one of dozen or less people staffing the library, then your UX work is likely bundled in with other job responsibilities. Some libraries are large enough to support a whole unit or division devoted to UX (or at least web services, web oversight, etc.)
  • How directly can you make changes to the website (and its attendant ecosystem services and resources, such as the link resolver, the discovery layer, subscription databases, catalog records, proxy server, ejournals knowledgebase, etc.) or to physical locations in the library where you want to work your magic?
  • What is the culture of change in your library? Do proposed changes and new initiatives tend to get debated to death? Does everyone have to weigh in on decisions?
With those considerations, here are some suggestions for someone just getting started as the sole person with UX responsibilities (or a UX job title).
  • Find your tribe inside and outside the library. In the library, look for people who are open to user-centered services or user-centered design so that you can have someone to bounce ideas off of. If that person happens to run a service or manage a resource that you’d like to do some design work on, all the better. Outside the library, you’ll want to find communities of people in libraryland who are interested in talking about UX work and communities that serve a broader UX professional audience. For me, this includes:
  • Dive into “the literature” (I’ll only mention a few books, as there are dozens worth reading)
    • Useful, Usable, Desirable. A great book about UX in libraries by Aaron Schmidt and Amanda Etches to get started with. Especially useful is the way the book is organized to help you assess all aspects of your library to help you identify where you might want to begin your design work.
    • Rocket Surgery Made Easy. UX expert Steve Krug’s book about usability testing and design work.
    • Don’t Make Me Think. A revised edition of a classic book by Steve Krug about UX and web design.
    • Weave: Journal of Library User Experience. Open access FTW!!!
    • LibUX. Check out the archives of this podcast and make sure you subscribe to it.
  • Carefully gather evidence from user research and save it in a mindful fashion as you work on projects. It is essential to draw on this evidence when making formal proposals for some change you’d like to make. The more you can show your colleagues that design decisions can be driven by evidence and not whim, the more likely they’ll listen to you.
  • Do usability tests on existing systems and services to identify and properly document problems.
  • Learn as much as you can about project management, as a lot of UX design work is a multi-step process that usually involves your collaboration with colleagues who may not always see the big picture of the project.
 I’m sure there is more to add here (for example, take a look at this nice guide about library UX from Carli Spina at Harvard University for more ideas). If I’ve forgotten something important, or gotten something wrong, please share your comments!

No Longer a UX Shop of One

Last fall, I was given the OK to hire a part-time user experience designer, which meant that my library’s user experience team was no longer a one-person operation. For the past four years, I’ve been working mostly on my own, although I frequently did projects that paired me up with others in the library (such as the time I worked with the head of access services to set up our new online reservation system for group study rooms).

One of the issues I’ve been working through over the past four months since I gained a part-time colleague is communication. Since it is no longer just me here, I need to be more intentional in sharing information. Although there are services to help you with project management in a team setting–things like Asana and Trello–I’ve found so far that a more low-key technology seems to be pretty good far: an internal wiki.

I’ve been using our campus’ wiki system from Confluence for many years now and feel pretty comfortable creating a new space there for the UX work my colleague and I are engaged in. In case it is useful to anyone else, I’ll share the set up.

First, there is a main page that lists all the projects in the pipeline. The project list is organized into high, medium, and low priority groups. Each project gets its own page. Each project page has these sections:

  • The Problem. A quick statement of what problem we are trying to solve with our UX design approach. For example, on the project page for “Databases by Subject,” the problem is that the current page requires too much scrolling.
  • Research Questions. As we start to dig into each project, we try our best to consider what it is we really don’t know but probably should if we hope to do the project in a way that aligns closely with user expectations. We want to make sure that we are questioning as many of our assumptions as possible. These questions will guide our efforts to understand our users before we get to the stage of producing high fidelity mockups. With the “Databases by Subject” page, the questions we have include things like:
    • Which is better for users: an alphabetical list of subjects or chunking the subjects within broad categories?
    • If we do use categories, what are the best category labels?\
    • If we do use categories, should we still have an A-Z drop down menu on the page that simply lists databases by name?
  • Design Ideas. At all stages of the project, we’re finding we have lots of ideas, both big and small, that may help us when we get to the mockup stage. This is a place to quickly note those. For some projects where it’s likely there is more than one distinct direction to go in, we’ll have a subsection of “General Design Principles” that apply to different options and a subsection for each specific option. For example, we are working on a redesign of the central search box on our home page. We’ve got a general principles subsection to specify things we should include and we’ve got subsections for the two main design options we have: a box with a drop down menu or a box with tabs on top.
  • Milestones. This is a list of the main tasks we’ll need to accomplish. In Confluence, these can be styled as a proper to-do list, which I like because of the satisfaction I get from ticking off a check box once some milestone has been reach. I probably need to read up more on project management techniques to see if it makes sense to break this section out from the Project Timeline section that we also create.
  • Project Timeline. This helps me get a rough sense of the flow of the project and think about how the deadlines align with the academic calendar, which is important as some changes we’d like to make are so major they really shouldn’t go live until the end the semester.
  • Project Documents and Files. We’ve been using a shared Google Drive for mockups, usability test recordings, screenshots of other websites, etc. It’s easier to use Google Drive for this than to go to the trouble of uploading it all to the Confluence wiki.
  • Sources of Evidence Used. This lists the evidence of user behavior that we will use throughout the design process. For a project we’re doing now to redesign  the central search box on the library’s home page, the list includes Google Analytics event tracking data on use of the tabs on the existing search box; usability tests; and query log analysis. The items on the list may link to a new page just about that item if it is a big enough thing. That’s the case with usability tests, which are usually big enough endeavors to merit their own pages in the wiki; so, for example, we have a page just about the details of the initial usability test run last December on the central search box.

I’m hoping all of this project management work will help me when the time comes to make the case to various stakeholders in the library about the design change I’d like to make. Depending on the scope of the change being suggested, I may need to write a report detailing the research that went into the recommended design.

This system of using a wiki for project management has really helped us organize the work better. I suspect, though, that the “to do” aspects of it need some more work. I’d rather not use a separate system to manage that and hope to figure out more ways to use Confluence (for example, I haven’t taken advantage yet of the ability to tag people in Confluence with an @ symbol to assign them tasks). For now, though, I feel like we’re in a better place with this kind  of shared documentation.

User Research Participants as Experts

Listening to Whitney Quesenbery’s interview of medical anthropologist Francine Harris on the UIE Brain Sparks podcast, I was struck by the suggestion that Harris made that UX researchers and designers should move away from thinking about the people who participate in the research as “subjects” and instead consider them to be “experts.”

Subjects reflect an inherently passive role in a research project. Researchers administer questionnaires that are designed by the research. They analyze results.

They do lots of things that confirm the expertise of the researcher. But, in reality, subjects are the experts. They have the knowledge that we want to understand and use. The question that researchers and designers need to ask themselves is, “How do we find out what they know?” It’s as much an attitude towards research and people. It has implications for how we define our research goals.

The interviewer, Whitney Quesenbery, then suggests to Harris that “it sounds like a big shift in your attitude about your research” from a position of ‘I am the person in the white coat studying things’ to ‘I’m engaging with people as I work with them.’” As someone who has done a lot usability testing, I find the mindset that Harris advocates compelling. So how do I think this might change my approach to designing research projects?

For one thing, I think remembering that the participant is an expert keeps my hubris in check. It’s easy for me to get carried away in thinking I’m the expert, I’m the person who knows this and that about user behavior and best practices, etc. But if I was such an expert, then I wouldn’t really need to do much testing. I’d already know everything I need to know.

My users are the experts, and it is up to me to continually be going back to them to understand how they use our systems. Yes, as a librarian, I know that there are more efficient ways of doing things in our systems and that sometimes there are even ways of doing thing that are objectively “right.. But that really doesn’t matter to me so much as a UX researcher. I’m not a user of our systems in the same way our primary audience is, or if I am, I’m a very special case (as are all of my fellow librarians). The “experts” at using our systems are the people these systems are primarily designed for (at my library, that would be the students and faculty of the college where I work). These experts are using our systems in their own way, not necessarily the way a librarian would (but that doesn’t matter). My job is to consider them as experts and then try to understand how they approach our systems, how they interact with them, what mental models they have in mind as they use our systems.

Keeping this perspective–that our users are our “experts” that we need to learn from and understand–will prevent me from designing research questions for projects that are flawed because I’ve fooled myself into thinking that I already “know” what I’m going to find. When it comes to analyzing usability tests, this perspective can help me maintain a more open mind about what I’m seeing.

And, finally, I think it will allow me to be more open to design suggestions from our experts. We should be fitting our systems when possible to their way of doing things, not strictly our preconceived models of what’s best for them. This last point speaks to what Harris was getting at when she mentioned that “subjects reflect an inherently passive role in a research project.” Later in the interview she talks about “participatory action research” as a method whereby the people being studied can play an active role in developing the research agenda, in analyzing the results, or designing solutions. I’m going to have think about that some more to see if there’s a way to bring that kind of collaboration into the UX design work I’d like to pursue. Stay tuned.

Sometimes More Is Less

This year, I’ve been doing a lot of thinking about search boxes on library home pages. I’m gearing up to present a plan for redoing the one at my library in the next year and have spent a lot of time looking at how other libraries have solved this design problem (I’ve also been looking closely at search on lots of commercial websites, such as Amazon, eBay, Wal-Mart, etc.). One thing I would love to test with users is whether you can get away with “____ and more” as a search scope label.

Many library sites let you focus your search to the catalog, the e-journal lookup system, a discovery layer, the library site search, etc., and label them with some name that identifies the kind of search tool it is: Library Catalog, Site Search, A-Z Journals, etc. Other libraries go the route of deprecating the name of the tool and instead focus on labels that identify the format of information to be found with that search scope: books, media, articles, journals, etc.

When libraries label the search scope by the format of what can be found there, they find that a single format label may not always accurately identify what you can find there. So instead of a label for “Books,” which searches the library catalog and will actually yield records for journals, DVDs, etc., it’s common for libraries to use the label “Books and more.” Often, you’ll see clusters of the “________ and more” labels on one site:

  • Books and more
  • Articles and more

Sometimes you’ll find that the label still uses the tool name (e.g., “Library Catalog”) and offers in smaller letters explanatory text (e.g., “books and more.”)

I’d be willing to wager that if you were to ask your users what they think might be included in the “more” category, you’d be let down by their wild, very off-base guesses. This is of course a testable claim I’m making. I don’t know if anyone’s written up anything about this very question of “what does and more mean to you” but would love to read it if it’s out there. Until I find such evidence or do my own testing, consider me skeptical about the value of “____ and more” as a link label or explanatory text.

Troubleshooting Electronic Resource Problems Reported by Students

Although my job title is user experience librarian, I help out quite a bit with managing electronic resources in my library. Over the past few years, I’ve gone down deep in the weeds countless times trying to figure out what went wrong when a user reported being unable to access an electronic resource. Some times it’s just one article, some times it’s an entire database. The possible points of failure (or confusion) for the user are many. Here’s an exhaustive list (for me, at least) of what commonly goes wrong for our users.

user names and passwords

  • entering the wrong user name and/or password (e.g., typos, misremembered logins, etc.)
  • not knowing what their user name and password is
  • not realizing that the resource requires you to create your own username and password
  • trying to access the resource by going straight to the resource via web search instead of using library’s link (that goes through some sort of authentication system)
  • user has logins for more than one institution in a consortium and uses the wrong one

authentication systems

  • trying to access the resource by going straight to the resource via web search instead of using library’s link (that goes through some sort of authentication system)
  • resource hasn’t been listed correctly in the authentication system (URL for the resource has changed)
  • resource requires some new special set up in the authentication system
  • user is from another library (that may be part of a local or state consortium) but doesn’t realize that resource is strictly limited to users at that specific library
  • authentication system is blocked by firewall/security settings on user’s computer or network

browsers

  • database requires specific browser (often Internet Explorer)
  • browser settings need to be changed to allow for specific functionality in the resource

licensing issues

  • user is now an alum and doesn’t realize off-campus access is now gone
  • license doesn’t allow walk-ins and/or alumni to use database

problems caused by the vendor

  • resource is down for all subscribing institutions
  • database is searchable but full text links no longer working
  • vendor has mistakenly shut down access for the library
  • vendor has intentionally shut down access for the library because of suspicious use or expired license
  • vendor hasn’t communicated changes in its holdings to services that rely on that information (such as knowledgebases that help libraries keep track of online journal access)
  • database has agreed to an unusual restrictive license from a publisher whose content is aggregated (e.g., EBSCO and Harvard Business Review)
  • library has cancelled subscription but forgot to remove all links to it on their website, catalog, discovery layers, knowledgebases, etc.

availability options

  • user doesn’t notice the full text links on a record
  • user unaware of interlibrary loan as a service option
  • user has found content that isn’t part of a library’s subscription in a database
  • user unaware that resource might be available elsewhere as open access (e.g., in an institutional repository, on the author’s website, etc.)
  • user has found book or periodical record in the catalog but doesn’t recognize that the resource is print only

out of date info in knowledgebases

  • library has incorrectly listed a resource as something that is subscribed to
  • journal publisher or database publisher hasn’t communicated to the knowledgebase vendor changes in holdings (I’m looking at you Gale)
  • knowledgebase vendor hasn’t yet updated their system with latest info from journal publishers or database vendors

OpenURL linking

  • database where citation-only record was first found failed to create a properly formed OpenURL
  • database that the link resolver menu sent the user to is unable to properly interpret incoming OpenURL
  • user didn’t notice link resolver option in the database (usually labeled locally as “Find it at [name of institution]”)
  • user didn’t understand what to do in the link resolver menu

URLs

  • user is trying to re-visit a URL saved from a previous session (instead of using a permalink)
  • permalink that the user got from the database results previously didn’t include URL syntax that would route it through the library’s authentication system
  • permalink that the professor put on the course website or the learning management system isn’t proxied

problems specific to ebooks

  • user expected full book could be downloaded
  • user didn’t realize complexity of getting started (such as registering for an Adobe ID)

problems specific to articles

  • user has a found a short article but mistakenly believes it’s not the whole article