Claim Returned for FOLIO
(requirements analysis through individual and group interviews)
As a product owner for the FOLIO library management system, I regularly meet with subject matter experts to gather requirements for loans-related features. These meetings follow a pattern established long before I came on the project: a conference call with 10-15 SMEs, with decades of experience in academic libraries across the U.S. and in Europe.We compare screenshots from different systems that they currently use, and discuss what works in their current practice and what doesn't. I summarize our discussion by wireframing a new design, then bring it back to the group for further discussion before writing up a story for the developers.
Sometimes, that works well, like when the interaction itself is simple or when there's a lot of similarity between systems already. For example, changing the due date for an item isn't a complex, and everyone's systems seemed to approach it in the same way: the user selects the item whose due date they want to change, they get a pop-up to select the new due date and double-check that they've selected the right item, then they enter the date and confirm. End of discussion.
Here's where that doesn't work as well:
- Where there are vast differences in how current systems support the interaction
- When institutions have differences in policy around the interaction
- When the interaction part of a larger workflow that takes multiple people months to complete
About five minutes into our discussion on claim returned, I knew that this was going to be a doozy.
what's claim returned?
Every so often, a patron will come to the library and say, "Why did I get an overdue notice for this item? I turned it in weeks ago!" Because the patron is claiming that they've returned the item, the library conducts a search for the item: maybe it was shelved without being checked in. During that process, the patron's overdue fines for the item are suspended, even though the item will remain on the account. However, all searches must end, and if the item is never found, the library has to decide whether to believe the patron that they did return the item, or to treat the item as if the patron lost it.
smaller discussion group
Even though the group agreed on a definition of claim returned (see above) relatively quickly, we were a long way off from agreeing how the system should support it. Because this and other loans issues were more complex, we broke out into a smaller subgroup, which met over the course of months.
The downside of the subgroup was that it didn't represent every school involved on the project. On the other hand, it was small enough that we could build rapport quickly. The six librarians I was working with mostly knew each other from previous work on the project. As the relative outsider, I was able to more deeply engage with the people involved instead of frantically trying to gather everyone's opinion, which built more trust within the group.
But claim returned, as a workflow, is still pretty thorny. It requires an understanding of item status (contentious), fines and fees (not my area of expertise), and bookstacks searching (so this digital workflow had to support physical workflows as well). It would have been great to discuss step 1 of the process, then steps 2, 3 and 4. But there were so many layers to each decision that it was impossible to chunk the work neatly.
Instead of taking things one step at a time and discussing all schools at once, then, I decided to do the reverse: Look at one library at a time, and discuss all steps at once. I canceled one week of the subgroup's regular meetings so I could meet with each person individually. I drafted some interview questions, but ultimately wanted to approximate a contextual inquiry approach as much as possible. Even though I'd be consulting with most people remotely, they were happy to share their screens with me and answer my many probing questions: "Then what happens?" "But what if..." "Tell me more about..."
Though it wasn't an option to conduct most of these sessions in person, I work at an academic library, so I was able to ask our staff to walk me through the workflow in person. This conversation extended to sitting down with the library's claims assistant and finding out how she searched the stacks. Having in-house experts to consult was incredibly valuable, though I was careful not to privilege my findings from those sessions over those from the remote interviews.
reporting and impact
Though the usual documents generated by the usual group discussions were wireframes, I wanted to make this problem more abstract at first. Putting together a wireframe would invite questions on buttons, labels, and layout, and I wanted to make sure I understood the steps of the process first.
After each interview, I used my notes to make a rough flowchart of each school's process. Then, I looked at the flowcharts together to see where they had things in common, and made one larger flowchart - just with a few more decision points, to reflect each library's policies.
Asking the group to approve the flowchart helped reinforce the idea that I didn't want to disrupt what they were doing. Instead, I wanted to understand the process so that I could make sure the system supported it. From there, we were finally able to get to the original first step of the process: wireframes. The time spent was well worth it, and introducing different research methods into the established patterns laid the groundwork for more productive and flexible research on future work.