Ideas that I hope will become trends: communication

If you missed the first post in this short series, you can catch up here. The first post was about user stories and focused on a presentation that I saw at the Heads of Technical Services IG meeting.

The second idea that I hope becomes a trend is open dialogue between catalogers and, well, everyone else. The genesis of this was a bullet point from the presentation that Scott Piepenburg gave at the Competencies and Education for a Career in Cataloging IG meeting.Piepenburg's presentation was about what Catalogers would need to be able to do in a post-AACR2, post-MARC world. One thing that he suggested is a must is that Catalogers need to not only understand what their ILS can (and cannot) do, but they must also be able to communicate these limitations to others.

It took everything I had not to jump for joy or to stand on my chair and cheer. I didn't, though. It was a small room and kind of crowded.

I think that catalogers do a pretty decent job of understanding the limitations of our ILSs. We spend a lot of time working with them and, as a general rule, get what they do both well and poorly. Where it breaks down, sometimes, is communicating this information to our colleagues. Whether it's our colleagues in IT or our colleagues staffing the front lines, it is our job to communicate well with them.

Having a basic knowledge of coding can help us communicate more effectively with IT staff. We don't have to be coding wizards, but we should be able to talk about how our systems do parse out data in MARC records and, perhaps more importantly, how we wish they did.

Having a basic understanding of how users search for information can help us communicate more effectively with front line staff. We don't have to spend a lot of time on the Reference Desk (though it wouldn't hurt), but we should be able to talk about how users can do more effective searching.

So, how do we become better at communication with others? I have a couple of ideas:

• If you want to learn the basics of coding, Codeacademy can help. They even have a program called Code Year which will walk you through the basics of languages like Javascript. And if you're looking for support, there's a CatCode wiki whose function is to support dialogue between coders and catalogers. In this case, I suspect it's a lot like learning the language when you visit another country. You don't have to be proficient in it, but the natives appreciate that you're trying to speak their language.

• Attend (open) meetings in departments other than your own. At my former place of work, there was a monthly meeting of subject librarians that was open to all interested staff. I didn't go every month, but I tried to go fairly regularly. Attending this meeting helped me understand the challenges that subject specialists faced when helping users which, in turn, helped me think differently about the work I was doing. This meeting was also sometimes the only way that I learned about issues that I could help solve but that nobody thought to tell me about--not because they were trying to leave me out of the loop, but because they didn't realize that the problem could be solved.

• Get your hands dirty in projects that involve other departments. Though the bulk of my job duties involved cataloging, I taught in my former place of work's Freshman Writing Seminar. I also worked with our Digital Library Services unit and our Web 2.0 initiatives. I made valuable contacts and learned a lot about what other people the organization do. 

I think the moral of the story is that it's all about relationships and empathy. Learn to speak the language of the people you work with. Be friendly and empathetic and take the time to answer questions that your colleagues have about the work that you do. 

What are your suggestions about developing rapport with other units? How have you opened the lines of communication?

Be visible. Be proactive. Be awesome.

Ideas that I hope will become trends: User stories

One thing I have learned after attending ALA's midwinter and annual conferences is that, if you pay attention, you can spot the beginning of trends. Is there more than one program on a particular topic? Consider it a trend. Is it an idea you've heard at multiple programs? Consider it a trend.

And one thing I've preached is that after you spot a trend, you have to figure out how your library is going to deal with this trend. Maybe you find a way to implement a trend into your library's operations. Or, maybe you consider a trend and decide it's not for you. But either way, you have to consider it.

At ALA's Annual Conference, I noticed a few interesting trends that are worth considering. Over the next couple of days, I'll write about these trends--starting with the idea of user stories.

Okay, so let's talk about user stories.

If you're familiar with software development, you're probably familiar with user stories. Essentially, you interview users to find out what they need a piece of software to do. These stories inform the software's design process. It's an opposite way of thinking than the usual business of most libraries which is to offer solutions that they think will meet a user's needs.

I attended the Head of Technical Services IG and heard about how the University of Chicago used user stories to inform the catalog design they worked on. They conducted 20 interviews and, from those interviews, they identified 200 unique stories. These stories fell into categories like browsing, composition of full records, and integration with other tools.

I like the idea of integrating user stories into any major design or redesign of a library resource. Libraries often believe that they know what their users want a piece of technology to do. Whether it's a citation manager or the library catalog, we think that we know how users work. And many times, we can bring anecdotal evidence to support that. Sometimes we even do usability testing to choose between options we've identified. But none of these things give users a voice during the initial phase of designing a resource or deciding which resource to purchase. Often, by the time we ask our users for their $0.02, the decision has already been made. And we try to do our best to help users live with the decisions we made by training them on how to use the resource we've purchased. But how many times have you taught a class on a piece of technology and had to tell someone that it doesn't do what they really want it to do?

How would things be different if we let the users tell their own stories and then found ways to solve those problems for them?

We might make different choices about the technology we decide to purchase and we might find open source solutions that meet our users' needs better than vendor-supplied solutions. 

We also might start asking for more from our vendors in the way of flexible implementations. Rather than purchasing the solution that comes the closest to doing what we think our users need it to do, we can approach vendors with evidence that we need them to provide implementations of solutions that do what our users actually need them to do.

So...now that you know what a user story is and have heard about someone doing it well, how will you integrate this trend into your library? 

Be visible. Be proactive. Be awesome.