Stuck between stations

As we move toward a post-MARC future, there is an increasing interest in bringing into alignment the metadata creation community and the library technologist community. This interest seems to be based on the understanding that the way in which we describe our resources needs to be in alignment with the way in which we build our systems to manipulate that metadata.

I have written before about metadata and user experience and the relationship between metadata creators and library technologists. I'm definitely in favor of finding areas of mutual concern between these two communities and leveraging that to build a more collaborative future. In fact, I think if you demanded that I tell you what I think the Unified Library Scene is about, I would probably say it's about building a collaborative future built on areas of mutual concern. I write and talk about that past the point of ad nauseam.

So, yes. Let's do that. Let's build a collaborative future based on areas of mutual concern between metadata creators and library technologists.

But do you notice who is absent in this discussion?

We cannot take users out of the equation when we're creating metadata and designing systems to manipulate that metadata. We are not building library systems or creating metadata for ourselves. But if we want to build user-centered libraries, it should matter at least as much to us (and probably more) what our users require from our metadata and our systems than we want them to be able to do.

The best way to understand user needs is to talk to users. But in situations where that doesn't work, our public services colleagues can certainly act as a conduit of information. They can teach us about the points of pain that users face when they try to access library resources using our metadata and our software. And from there, we can understand what can be easily be fixed in-house and what needs to be addressed at the developer level.

This isn't a new idea. Agile software development uses this method in developing user stories. User stories are useful because they give voice to user needs. In a post-MARC development world, a public services colleague can be a valuable resource in developing user stories about metadata and systems use.

This is a good time for us to pause and acknowledge that certain aspects of our metadata and our systems are, in fact, built for us. We need systems that do inventory control and request fulfillment. And some of the metadata we create is administrative. And those needs come with a certain set of specifications that are separate from what users require from our systems. But let's not confuse creating standards and software that support librarian needs from creating standards and software that support user needs.

Turning our attention toward actual user needs instead of perceived user needs has the potential to be uncomfortable. It may require a redesign of our standards and systems which may, in turn, require a reallocation of our staff efforts locally. But I think this is where we can learn something from software designers and the agile software development movement. If something isn't working, agile software developers move with changing requirements until is does work. Because creating software that doesn't meet user needs is essentially a waste of time and money. And so it is with libraries. Throwing staff time and resources at metadata creation and systems development that aren't working is essentially a waste of time and money.

I think that a good starting place is to involve our public services colleagues in conversations about our post-MARC future. By allowing them to help us understand user needs, we can begin to create metadata and systems that support them. Even if that metadata and those systems aren't what we expect them to be.

Stay positive,
Erin