Kate McManus

Implementing LibGuides’ Publishing Workflow

Three Easy Steps

Kate McManus is virtual reference librarian at the University of Minnesota – Twin Cities, email: cmcmanus@umn.edu.

© 2026 Kate McManus

In 2022, Urszula Lechtenberg of the University of Pittsburgh and Helene Gold of the New College of Florida presented on “When All You Have Is a Hammer, Everything Looks Like a LibGuide” at LOEX.¹ They began their legendary presentation with an Airing of Grievances. The word cloud that was collectively developed in that room matches my LibGuides notes/conspiracy board to the letter: “messy,” “overused,” “not a methodology,” “TABS ARE THE WORST,” “long list of links,” “students don’t use them,” “pedagogical crutch,” etc.

All of this, as well as being the LibGuides lead since 2019, informs my thinking when I’m trying to be strategic about LibGuides. I’ve focused on two things in two years: “never updated” and “so disorganized.”

According to Springshare,² as of the end of 2025, library staff have created 957,439 total guides by 315,465 guide authors across 5,731 institutions in 104 countries.

At the University of Minnesota (UMN) Libraries, we have 946 published guides. Part of that is because when our web team planned our new Drupal site, most people lost direct editing privileges of the site, and any content on the main site underwent a review. Instead, they were encouraged to make LibGuides. I was new to the LibGuides role and scrambled to update and build out our documentation,³ especially guidelines for long-term management.

What we found in this environment was many more guides and our overall LibGuides structure trending toward the “never updated” and “so disorganized.” concern areas. I wanted to combine guides and foster a LibGuides ecosystem that relies on collaboration—and especially to review guides before they were published. I also wanted to review and refresh existing guides.

Obviously, that was going to take years of work, and they remain my guiding principles, but the review of guides before they are published IS in fact possible with a built-in Springshare tool.

It’s called the Publishing Workflow.

It’s a deceptively simple toggle to enable this feature, yet it took me two years to turn on.

Step One: Learn All You Can about the Workflow

Springshare’s documentation is a good place to start. When I began looking into the publishing workflow, I made a post in the Springshare Lounge⁴ on February 7, 2023, asking whether anyone had used this feature. I got three replies but very little practical guidance and a dire warning that it wasn’t very popular.

Here’s what’s in the documentation: When the Publishing Workflow is turned on, in the drop-down to change your publishing status, there is a new option to Submit for Review. If someone updates their guides or builds a new guide, they must use this option. They will not be able to publish a guide directly without going through this step. If the guides are already published, new content will not display until the review is complete. Guide authors can also leave a note for the review team.

If you are one of the Authorized Reviewers, you get an email when someone submits their guide for review. Your job is to review it against the rubric in your documentation, using tools you’ve already shared (we use the WAVE evaluation tool), and decide whether you’re going to publish the guide or send it back to the owner with clear instructions on how to fix the issues.

Here’s what’s not in the Springshare documentation that we had to develop on our own. First, make sure that there are multiple people who can review guides and that there’s a plan or workflow in place to manage the review. Communicate expectations to guide creators (e.g., we’ll process your guide in one to two business days, linking to documentation with a rubric). Find a way to track guides; we use a Google Sheet that’s shared among the review team. Springshare will email the guide owner when the publishing status changes, but outside of that procedure, we also send a personal note to each LibGuide author, especially if we made tweaks to their guide.

Step Two: Get Administrators on Board

This step took the longest. The first time I presented this to directors, they were not enthused by the idea. I can’t blame them. I didn’t have a detailed enough plan, I hadn’t had the idea for the review board yet, and I hadn’t written anything down on what would become our rubric. I also hadn’t been the LibGuides lead very long and had inherited a lot of unpopular decisions that it was suddenly my job to justify. The directors worried that a publishing workflow would feel punitive.

I spent the next two years listening and learning more about the LibGuides authors’ experiences and reading relevant literature. I implemented fixes and developed a new tagging system (with a taskforce, of course). Almost annually I did usability testing with our colleagues at UMN who are dedicated to testing the entire university’s website. I brought the student feedback to guide authors. I started more regular communications. I hosted LibGuides Edit-a-Thons to encourage folks to update their content and give them another space to listen to questions and concerns. I credit this idea to Natalie Ornat, Beth Auten, Reese Manceaux, and Catherine Tingelstad from their article “Ain’t No Party Like a LibGuides Party: ‘Cause a LibGuides Party Is Mandatory.”⁵ I live for a 30 Rock reference, and having space for LibGuides authors to co-work and manage their guide updates made a lot of sense to me.

I worked with our cataloging folks to surface guides in our Primo searches. I trained and sometimes retrained folks. I visited department meetings. I made accessibility a cornerstone of LibGuides work with a dedicated subpage of the documentation⁶ then visited department meetings to get the word out. In addition to the Accessibility subpage, I continually worked on documentation so that it was crystal clear on what guide authors had to do to make their guides accessible. I made our templates mandatory and applied them to guides that did not use them.

Not everyone responded to my communication and attempts to reach out, but the majority of my colleagues were willing to work with me. As I’m the one who sets up LibGuides accounts, no one gets an account without a training session. I was open and available to retrain anyone who was interested and, very occasionally, directors would tell their staff that my sessions were mandatory (I have a personal policy to record all my “mandatory” training sessions to share with anyone who was out that day).

When ADA Title II was announced, I had built up enough good will and a history of successful projects that when I once again broached the idea of a Publishing Workflow, most agreed that it was necessary. I assured them the rubric that the reviewers would use was already published in the documentation and was technically already mandatory. But without a formal review process in place, I could not ensure that people were following the documentation. There was still pushback, but ultimately administrators were on board with ensuring guides were at least accessible—legally they had to be.

Step Three: Toggle on the Workflow

After I got buy-in from our leadership, I was able to form a review board of myself as a permanent member and three other guide authors who can roll off after one year. I added them to the list of Authorized Reviewers. On a Friday in June when no one was likely to be working on their guides, we tested the workflow, careful to turn it off again. This helped us formalize our documentation and plan our own procedures.

Over the course of four months, we worked together to build our procedures. We also divided the work as evenly as we could, each taking charge during a month for the guides that would come in. We opened a Slack channel for more informal feedback and quick announcements from the review board.

We also divided up the department meetings our LibGuides authors regularly attended, visiting as many people as we could in a short time. The directors were very generous in giving us that time. We reshared the documentation, paying special attention to the rubric and changes to how guides are published. We also highlighted other tools we would be using, primarily the WAVE evaluation tool. We hosted a final open-call meeting for all LibGuides authors in case anyone missed us at their department meeting or wanted to hear the presentation again. We recorded the meeting, linked the recording in the documentation, and shared it via email.

On August 4, 2025, we turned on the Publishing Workflow. When a guide creator finishes a guide or makes changes to an existing guide, they submit it for a review.

When we review a guide, the first thing we do is enter it into a shared tracking Google Sheet. We compare the guide to our rubric, checking any links and fixing typos or more often: change “Title Casing” to “Sentence casing in our headings.

When training folks, we told them that if a guide took longer than fifteen minutes to fix, it would be sent back to them with a list of changes and offers for support. So far, that hasn’t happened once. Those who have not previously engaged with me about LibGuides or weren’t using the documentation were passing their reviews as well. Only one person reached out, baffled at the change in LibGuides. No matter how careful you are to communicate, don’t feel bad if you can’t reach everyone.

There were a few growing pains, particularly those who were editing a guide and didn’t understand that they had to submit even published guides for review. We only had two emergency “Oh no, I teach this afternoon” emails that we were fortunately able to accommodate.

The workflow is on, and it’s staying on. And of course, that was only one of my own personal grievances with LibGuides.

Reflections and Conclusion

I lied when I said that the steps were easy. Everyone I work with has a different relationship with LibGuides, and everyone has a different idea of what we should do about them. If you are the LibGuides lead at your institution, you know the push-pull of having so many people with thoughtful and sometimes competing ideas and priorities. I see LibGuides as a balancing act, but the audience I’m always trying to think of is our patrons. If you can find that common ground with your colleagues, the three not-easy steps will become three manageable steps.

Because this is only one piece of solving the issues of “never updated” and “so disorganized,” step four will be reviewing the guides that were published before August 4. I’m planning on a massive review, not just for accessibility but also for content updates, tags, and content strategy (and organization). Although I still have a list of grievances (and open tickets with Springshare with ideas on how to improve LibGuides overall), I hopefully have changed our not-so-little ecosystem into one that’s collaborative on the back end and easy to navigate on the front end. If the previous steps were on a treadmill, I’m about to turn on the stair climber.

I would absolutely suggest that anyone concerned about LibGuides at their institution consider turning on their Publishing Workflow as one piece of their overall strategy. Take my advice: you cannot do it alone. Set up a structure for folks to know exactly how to submit a guide that will pass the review. And have a team review the guides. Having firm guidelines and structures has mitigated some of my grievances with LibGuides.

Notes

1. Urszula Lechtenberg and Helene Gold, “When All You Have Is a Hammer, Everything Looks Like a LibGuide,” (LOEX), 50:35, accessed December 22, 2025, http://bit.ly/4sEG6uL.

2. “LibGuides Community,” https://community.libguides.com/?action50.

3. “LibGuides at UMN Libraries,” last modified December 1, 2025, https://libguides.umn.edu/basiclibguides.

4. “Publishing Workflow in LibGuides,” last modified June 27, 2024, https://lounge.springshare.com/discussion/1343/publishing-workflow-in-libguides?utm_source5community-share&tab5accepted.

5. Natalie Ornat et al., “Ain’t No Party Like a LibGuides Party: ‘Cause a LibGuides Party Is Mandatory,” College & Research Libraries News 82, no.1 (2021), https://crln.acrl.org/index.php/crlnews/article/view/24766.

6. “LibGuides at UMN Libraries – Accessibility,” last modified December 1, 2025, https://libguides.umn.edu/basiclibguides/accessibility.