Item Status

the challenge

Item status (the field that tells you whether an item is checked out, on the shelf, or elsewhere) is one of the most visible fields in a library services platform. It's used by many library staff in a variety of workflows, and to accommodate these workflows, each library defines and implements item status in a different way.

Item status can comprise multiple fields, or just consist of one. It can be a repeatable field, or not. It can convey information about whether an item is checked out to a patron, or information about whether staff are using an item, or both.

As the product owner for item status in FOLIO, an open-source library services platform, I needed to address those aspects. While the system had a field called item status, it had been developed without a larger vision for what the field could do. Discussions of item status were usually siloed within small groups of subject matter experts. There was interest among one group of subject matter experts in expanding the scope of that field, but it was difficult to communicate that interest to everyone participating in the project. As a result, development stalled.

It was my job to bring together stakeholders in many departments at many different libraries and secure consensus on the requirements for item status across the project.

approach

scoping the work to be done

I took an inventory of all the features in the backlog that centered around item status, and all the previous discussions that had been had on the topic. For each feature, I came up with a list of questions I needed answered before development could move forward.

Two years prior, I and other product owners had worked with resource access librarians and proposed an expansion of item status into three fields. Breaking item status down into three fields would allow the system to track both the availability of an item for check out and whether it was being used by librarians in particular staff processes. But that proposal had never been adequately communicated to other librarians contributing to the project, so I added it to the list of features that needed to be discussed.

forming a working group

Based on my prior experience in the project, I estimated how many hours of subject matter experts' time I would need to answer questions about the item status features. Because item status was central to the project, I knew that many stakeholders would want to give their input, but I didn't want to take advantage of their time.

I then met with existing groups of subject matter experts to recruit contributors for the item status working group, and shared my list of features to make expectations clear upfront. Nine people representing three different areas of librarianship volunteered, and consulting everyone's calendars led to a meeting time that worked for seven people - a good balance of manageable group size with a variety of interests represented.

discussing features

The group met weekly for four months (just as estimated!) to discuss workflows and wireframes. When there were workflows I needed to understand more deeply, I held one-on-one meetings in lieu of working groups. But those one-on-one meetings were rare. The advantage of this working group was that it combined subject matter experts from different departments and institutions, so I wanted to meet as a group as often as possible to resolve disagreements or misunderstandings early on.

To aid discussion, I created wireframes when we were discussing new interactions. I kept them rudimentary, so that the focus could be on the logic and workflow behind the interaction, rather than font choices or color preferences. Designing multiple versions of each interaction allowed the group to compare and contrast, describing why one version would be helpful and others, less so.

Part of the discussion centered on how automated certain interactions would be. For example, should checking in a library book automatically change all item status fields, or should users change those manually? Bringing several versions of a check in modal to the group allowed us to discuss the pros and cons of each one. They also shared use cases where an automated handoff would be helpful, and use cases where they would prefer to manually change item status.

Even though the change at check in could be automated (with some input from and notification to the user), users also wanted some way to change item status elsewhere in the system. Once again, I created a few wireframes of what that might look like.

reporting and impact

When the group made a decision, no matter how small, I documented it in the project wiki. I could then go back to those notes when writing stories, and point other stakeholders to those notes if they were curious about how the group was progressing.

Since the item status working group was only a subgroup of other, larger groups, I presented the group's decisions at those larger groups as well. During those meetings, I welcomed feedback, but made it clear that I trusted the decisions the working group had made. Though some tweaks came out of those larger meetings, the audience was usually confident in the working group's decisions.

Convening the working group allowed me to better understand the concerns and priorities behind item status. Now, as the item status features move forward, it's with a larger vision in mind, one that takes into account how that field is used by many kinds of librarians. Though other questions will emerge as development progresses, the foundation laid by the working group for clear communication should make answering those questions a lot easier.