Patron Survey #1: Evaluating Then-Current Emails

We designed our first survey to assess how patrons perceived our then-current ILS emails.

Patron Survey #2: Evaluating New Emails

After our new email templates had been implemented for a year and had undergone a second round of minor changes, we wanted to get users’ impressions of them.

Most Frequent Findings

Across all our user research activities, there were several consistent findings about what our users wanted:

• more detailed information about fines and other relevant policies

• specific, informative subject lines

• better formatting

• language conveying the appropriate amount of urgency

Creating and Using a Style Guide

Organizations that have multiple people writing content can employ a style guide, either a popular one that already exists, such as the Chicago Manual of Style, or one that they create internally (Metts & Welfle, 2020). Style guides often provide direction about capitalization, punctuation, and words to use or avoid. Our library system already had a branding style guide, which included guidance about how to refer to our organization—“the NC State University Libraries,” not “the NCSU Libraries.”

However, the User Experience Department identified a need for a web style guide—one that addressed not just word choice, but ways in which writing for the web is different from academic writing. The Department wrote the guide for our colleagues with editing permissions on our website. We took inspiration from the Mailchimp style guide (Mailchimp, n.d.), which included sections about voice, tone, and content organization. In spring 2020, the User Experience Department published an internal web style guide (Boyer et al., 2020), which included these tips for writing for the web:

Writing for Stressed Users

A common writing tip for everything from college essays to advertising copy is to consider the audience. For whom is it written? On some campuses, when considering web content or emails for a university population, it can be tempting to imagine a “typical” user. Indeed, creating a persona is a common practice in UX. A persona is a “fictional, yet realistic, description of a typical or target user of the product … an archetype instead of an actual living human” (Harley, 2015). Personas are often described with character traits, background stories, and experience levels to generate empathy and a user-centered perspective while creating a product or content. In an academic library context, some projects may benefit from the use of personas (Hixson & Parrot, 2021). However, these personas often do not include disposition—they do not consider the mood or specific situation the user is in when encountering the product. Users can read emails anywhere at any time, so it’s important to consider the range of situations a user may be in when they open the email.

Instead of inventing user personas, we suggest creating situational personas when considering communication services. For instance, in the case of an overdue email template, one situational persona may be the user whose overdue book is currently in the bag they’re carrying. This user is on campus and can easily drop it off at the library that day. When they read the overdue email, it’s not a significant stressor. By contrast, a more extreme situational persona may be the user who is traveling abroad for a funeral service. This user’s stressful scenario is unrelated to the overdue email, but receiving that notice may serve to exacerbate their level of stress: this user might not know where the book is, when they’ll be able to return it, or how much of a late fine they will receive when they do. These users aren’t described by their hobbies, behaviors, or life stories. Instead, what matters is what situation they are in when they receive the automated email. Our goal was to consider the more extreme situational personas, not what we would consider “typical” ones, while rewriting our email templates.

The concept of “stress cases” from Design for Real Life informed our thinking about the audience for our emails and their situational personas. Rather than consider a typical user when writing or designing web content, consider what stressful situations they may be in, and design the content to be usable in that situation. “If someone comes to a site or an app in a moment of crisis, we bet they have a genuine need to be there—and that is the exact moment we don’t want to let them down” (E. A. Meyer & Wachter-Boettcher, 2016, p. 46). As we evaluated and rewrote our email templates, we considered how a stressed user or a user in crisis would react to the email. We repeatedly asked ourselves questions beginning with “What about a user who…” or “What if the user…?” We aimed to find a way to add the least amount of stress to our users’ already stressful lives, while still suggesting that they take action in response to some of these email templates.

One of our strategies was to include a short Q&A section addressing topics that our Ask Us student employees identified as common questions and points of confusion. For users who were engaged or worried enough by the first half of the email, we endeavored to answer questions that they probably had, such as whether they could renew their materials and how to check their account to view any fines. The objective of writing for stress cases was not to suppress information, such as the fact that the user has been billed for a lost item, but rather to explain the situation clearly, provide a next step, and do so in a way that communicated the lowest appropriate level of urgency.

This project started in March 2020. We had been discussing how to view our public-facing work through the lens of stress cases, which became even more important as the COVID-19 pandemic began. Every use and user could be considered a stress case. Logistically, the pandemic necessitated including information about policy changes in some email templates, such as a note about library branches that were temporarily not accepting returned items. We strove to consider compassion, calmness, and appropriate tone as we rewrote the emails.

Varying Tone

Using our style guide, we aimed for a consistent voice in our emails that matched the voice in the rest of our web content. However, with stress cases in mind, we varied the tone of each email depending on its contents. We were cognizant that the user might be reading the email in the middle of another task, and that communication is contextual. As Metts & Welfle (2020) noted:

[T]hings change depending on the following information: where users are in the journey; how experienced they are in using the interface; what their intentions are; [and] what their mood is: how receptive they are to what you are guiding them to do. (122)

We purposefully imagined users opening the email in a variety of scenarios, such as on their phone while riding the bus home in between reading other emails. For some emails, a happy or friendly tone would be appropriate in these scenarios, depending on the objective of the communication; for others, a more serious or authoritative tone would be more suitable.

The existing (old) email templates had last been edited extensively in 2012. They used a staid tone. As an example, here is the old template for emails that alerted users that a hold they had requested was available:

Subject: Requested library item available for pickup

This email felt stilted and overly formal, and the subject line sounded robotic. We felt that this was an email that could have a friendlier, more human, even more celebratory tone. We were inspired by Grand Valley State University Libraries’ email template, which one staff member there noted gave her a “spark of joy” (K. Meyer, 2019). Our revision:

Subject: Great news! Your library item is available for pickup

This example demonstrates three tone-related decisions. First, we replaced the salutation “Dear library user” with the more conversational “Hello.” Not only did that sound friendlier, but the linguist Gretchen McCulloch pointed out that some younger university students found that the word “dear” was “uncomfortably intimate, like calling your professor your darling” (McCulloch, 2021). The generic “Hello” was an appropriate salutation for all our emails, including ones about billing. Second, as part of the friendlier, more conversational tone for this template and some others, we used contractions (“we’ll”), something that the old templates avoided. Third, we allowed ourselves to use more enthusiastic punctuation. Overall, the old templates had zero exclamation points among them; our new templates had twelve total. With these three changes to the hold pickup notice, along with additional information about how long the item would be held for the user, we made this template more welcoming and informative.

For other templates, of course, we took different approaches to tone:

• Overdue notices: informative, though not dire (“You have overdue items from the Libraries. Please return them soon.”)

• Billing notices: serious (“Since we did not receive the following item(s) back on time, you have been fined for them.”)

• Hold canceled notice: apologetic and sympathetic (“We’re sorry, we can’t fulfill a request you placed 6 months ago.”)

By varying the tone of each email notice depending on its main objective, we were able to reduce confusion and communicate the appropriate level of urgency.

Structuring Content

As much as possible, we front-loaded important information in our email templates. We followed the inverted pyramid model, in which the most important thing to know comes first, followed by other information in order of most to least importance (Nielsen, 1996). This structure can be good practice for web content, and it is doubly important for emails.

We aimed to pack the necessary information into a concise, readable subject line. Since our ILS could only support a static subject line for each template, we could not accommodate a request that came up in our user research for dynamically changing subjects, such as “Due in 1 day: Apple MacBook.” Still, we did our best to summarize the important information for each template in the subject, for example: “Library items due in 1 day.”

Furthermore, we considered how the email would look to the user in their inbox, particularly on mobile. In a typical inbox, the user would see the subject as well as a snippet or preview of the email itself. This snippet would come from the top of the email’s body, so we aimed to make the first fifteen words or so of each template as informative as we could. This necessitated changing some settings in our ILS to remove cruft that appeared at the start of the email, which we’ll cover in the following section. As the Mailchimp style guide noted, the snippet can “[p]rovide the info readers need when they’re deciding if they should open” the email (n.d.). That style guide assumed the aim is for users to open emails as much as possible to achieve a high “open rate.” But our notices are not the same as a marketing email or newsletter, so we had an opposite reaction to the idea of boosting our open rate. A successful automated email from the library might be one that the user doesn’t even have to open: the user is reminded to take an action based on the subject and snippet alone.

Generally, our templates followed this content structure:

• The most important thing to know, such as that items are overdue (2–3 sentences)

• Item list

• Q&A section, such as “Can these items be renewed?” (2–4 questions and answers)

• Email and phone number for the Libraries

The Rewriting Process

We began rewriting our email templates in the spring of 2020. We split the process into three parts: recommendations, rewriting, and reviewing. Figure 2 shows how our rewriting process was intertwined with our user research.

Figure 2:

Project Workflow

Formatting

As with any ILS, system-defined elements often constrain customization. The current text-based email notice templates are composed of a mixture of customizable text blocks and system-controlled fields. The system defines the order of the notice elements:

• Heading message

• Item list

• Closing message

The heading and closing message text are the customizable text blocks that present the user with the reason for the notice as well as any general information that would be helpful to the user, such as hours and contact information. The item list provides information on the items, such as title, call number, date, fine amount, etc. However, the item format and elements available for output are set by the system with limited options for customization.

As part of our survey, respondents provided suggestions to improve the overall UX, such as listing certain information in bold and changes to time/date formatting for due dates and hold pickup times. Our respondents likely expected that these formatting updates would be feasible, considering the rich formatting of other automated emails that they receive, such as newsletters and order confirmations. But we couldn’t implement many of these suggestions due the nature of text-based email and system-controlled formatting. Given the feedback from our user research, providing these emails in rich text formatting is an option we will consider for future implementation.

Other challenges involved the display of hard-coded information that could not be removed from notice output. As stated, the snippet is an important part of the overall email communication that provides a snapshot view of the purpose of the email. Certain elements appear in a fixed position by default, such as the day/date of the notice, which was always at the top of the email. When elements that display at the top of the email cannot be removed or repositioned, they can cut into the snippet and limit the user’s ability to quickly skim information.

Finally, inconsistencies in the display options among the various notice template elements could result in an incongruous experience for users. For example, some notice templates would not allow us to remove the user’s address from the notice, while other templates gave the option to hide this information. Likewise, certain notice templates did not have an option to provide closing text, forcing information into the heading text that would be more appropriate in the closing text, such as general library information.

While we found that these issues did not negatively impact the overall interaction when the notice was positive, having to work within the constraints of the system forced us to make decisions on which information to prioritize and where to present that information.

Timing

The timing of the notice is just as important as its content, both for conveying context and driving urgency. For the information to be effective, it has to come to the user in time for them to take action, if required. To fully understand the implications of notice timing and how it relates to notice text, we looked at our loan policies—specifically, our short-term loan programs, such as tech items (eight-hour loan) and reserve textbook material (two-hour loan). Table 1 shows our notice schedule for various items.

For example, after a user checks out a tech item with an eight-hour loan period, they’ll receive one courtesy notice reminding them of the due date and time on the day the item is due, within an hour of checkout. If it is not returned, they will receive one overdue notice the following day—one day past the due date. After two days unreturned, the item will be “assumed lost,” and the user will be billed for the replacement cost and a processing fee.

For the most part, we were satisfied with the timing rules that were already in place, with one notable exception. Ideally, we would have liked to provide users with a courtesy notice for short-term loans closer to the date/time the charge is due. Providing an alert that the item is coming due within an expected amount of time would give the user the opportunity to take measures to return the item on time and avoid fines and ensure the material is available for another user.

However, the option to send a notice within hours or even minutes before an item is due is not available in the Sirsi reporting system that generates notices. The only criteria available for the “date due” selection for the notice job is “days,” “weeks,” or “months” before due. Additionally, the notices are sent via scheduled jobs that run every hour. Therefore, the criteria for the notice job had to be set to select charges that are due “today” where a previous notice had not been sent. This results in users receiving a courtesy notice within one hour of charging the item and shortly into the eight-hour loan, anecdotally leading to confusion or annoyance. For example, a user who checked out a laptop at 10 a.m. used to get a “due soon” notice at 11 a.m., 7 hours before their item was due.

When we revised this template, we turned it into a confirmation instead of a warning:

• Old subject: Library item(s) due very soon

• New subject: Thanks for checking out these items. Here’s when they’re due.

In rethinking this template, we were inspired by other automated emails that users might be familiar with: the order confirmation or emailed receipt. Moreover, we decreased the sense of urgency (“due very soon”), instead taking a friendlier, more conversational tone (“here’s when they’re due”). While the constraints of the system required compromise between notice text and timing, survey feedback was positive, with 89.4 percent of the surveyed participants stating they feel informed by the messaging. Additionally, the new templates received a rating of 4.5 in clarity on a scale from 1 (very unclear) to 5 (very clear).