Access 2023 Conference Lightning Talk

Usage stats are great and everything, but have you tried non-usage stats?

This is approximately what I said in my lightning talk at the Access Conference, October 25, 2023.

In summer 2022 I got it into my head that I wanted to look at not what people use on the website, but what they don’t use. Are there particular kinds of links that no one ever clicks on? Are people less likely to click on anything when confronted with a page full of links? What better place to find pages full of links than library guides? (Note: we don’t use LibGuides; our library guides are part of our library website, managed in Drupal.)

I scraped links from our library guides and matched them with web analytics from the previous academic year. It was super-messy and I did a really shitty job. But it helped me figure out how to do it better so I’d actually feel confident showing my data to people. So I redid the whole thing for Fall term. This time, I:

  • Created the list of guides and their links before the term was over and guides were changed or removed
  • Pulled links from the CMS (Drupal) rather than scraping from the website, which made it easier to get a clean list

In January, I grabbed the analytics from Fall Term and matched those to the list of guides. To get a list of links that had been followed, I combined Events and Previous Page statistics to get both external and internal links (Google Analytics has completely changed since then so that’s totally irrelevant now, but it’s what I did).

I matched the link data with the list of all links and where there was no match, that link got 0 visits. There was a lot of clean-up at this stage but finally, I had a list of all of our guides and every link in each guide along with how many times each of those links had been followed. (I also had pageviews.)

The idea was not to present this giant spreadsheet to each content owner, but for me to do some analysis to look for patterns in use or non-use. I did that analysis and wrote up a report and gave a presentation for our content owners in May 2023.

In a nutshell, this is what I told them:

  • Of 516 (!!!) guides, 130 had fewer than 10 visits in Fall Term, and 53 of those had fewer than 5 visits (we don’t filter out staff IP so this includes every time a content owner showed their guide in a class or to a student at the reference desk)
  • Guides with more links had fewer links followed. This showed up in two ways:
    • As there are more links on a page, the proportion of links that are followed even once goes down. Where there were fewer than 30 links on a page, 56% of those links were followed. Where there were 50 or more links, only 15% were followed.
    • As there are more links on a page, the number of times any link is followed goes down. For pages with fewer than 30 links, there was an average of 13.5 clicks per link. For page with 50+ links, there were only 0.5 clicks per link. When I presented this to content owners, I heard rumblings of “that’s just math.” But if it was just math, people would be clicking on the same number of links on every page and then graph would be very smooth. But this is the graph of the data and there is a nice cluster of engagement between about 16 and 29 links on a page and then the clicks per link go down quite quickly from there.
Graph shows number of links increasing smoothly while clicks per link go up-and-down but are fairly high until about 29 links then the spikes get much lower and mostly flatline around 45 links

There were no particular kinds of links or link text that were universally avoided, but links to the catalogue (Primo/Omni) were followed less often than other links. In Fall 2022, 84% of non-Primo links were never followed, but 90% of links to Primo were never followed.

My advice to content owners was to limit the number of guides, to provide a limited number of links to critical resources, and to be particularly sparing with links to the catalogue.

So: what happened? What do things look like in Fall 2023? Well:

  • In Fall 2022, there were 516 guides
  • In Fall 2023, as of last week, there were 536 guides
  • In Fall 2022, there were a total of 27,511 links, about 5900 links to catalogue.
  • In Fall 2023, there were a total of 26,939 links, about 5400 links to the catalogue.

So, there are more guides but fewer links, so maybe a bit of a win? <shruggie>

Was it worth looking at non-usage stats? Well, it made me even more confident telling people that less content is better. But when I look at the time I spent versus the effect it had: it was absolutely not worth it! Not the best note to end the conference on, but again: <shruggie>.

More Than Just Working Together: Reflections on UX Work and Collaboration OR It’s not just you (UXLibs Plenary Talk, June 2023)

This is approximately what I said in my UXLibs plenary talk on June 8, 2023 in Brighton. Or at least what I’d planned to say.

The last time I was at UXLibs was 2019. I had a poster and was recruiting participants for a research project on structures and supports for UX work in academic libraries. Some of you in the room took me up on that – thank you! – and I did interviews later that year. I was lined up to present some of those results at the 2020 conference. Oh well. But as it turns out, I think it’s a good thing that I didn’t do that presentation. Because if I had, I wouldn’t be doing this presentation. And I think this one is better.

I originally titled this talk “More than just working together: reflections on UX work and collaboration” partly as a blatant tie-in with the theme, but it is about collaboration and it is a reflection on that 2019 project on UX work. And not just my own reflection. I asked some of the original participants to reflect on the resulting article, published in WeaveUX in 2020. (Again, some of you in the room did that reflection – thank you!) Andy didn’t think the title was very punchy. He’s right. It’s very academic. There’s a colon there and everything. But this is not an academic talk. So, I’m changing the title. Although collaboration is more than just working together, that’s not really the main message of the talk. The main message of the talk is what I said or wanted to say to almost every person I interviewed for these projects: “It’s not just you.”

This morning I’m going to describe that first project very briefly, so that you know what people were reflecting on, I’ll mention why I wanted to do this reflection, and then focus on that collective – you could say collaborative – reflection on UX work and collaboration.

The original project: In 2019, I interviewed 30 people in 5 countries about how their UX work is structured and supported. I was hoping to find which structures and supports were most likely to set UX workers up for success.

The thirty participants worked in academic libraries in Canada, Norway, Sweden, the United Kingdom, and the United States. They worked in a wide range of libraries and had a wide range of UX experience.

I’m not going delve deeply into the findings, but will quickly look at the main themes that came through:

  • On the structure side:
    • Have a formal UX group: Participants with a UX department, committee, or working group saw their UX work had big impacts in their libraries.
    • If you don’t have a UX group, working with an informal group of colleagues led to some impact, including shifting the library culture toward UX.
    • Not surprising, given the above, involving colleagues in UX work had a positive effect on UX workers.
    • Authority to implement change is important: Participants who cited impacts were able to directly implement changes or ensure that others did so.
    • Move beyond web UX: Participants with a web focus struggled with a lack of support, lack of authority, and a lack of impact.
  • And for support:
    • Concrete management support is important: Participants who cited impacts and support from colleagues also pointed to management interest in UX and staff being allowed time to do UX work.

I was hoping to apply these findings to a new role in my library. I worked with my boss and my boss’s boss to change my job description to include UX beyond the website. They supported the creation of a UX Committee, as I wanted to structure in the involvement of colleagues, including a senior manager to oversee the committee. I hoped this would confer some authority and make management support concrete.

Two years later, I felt like the committee wasn’t effective and I felt like I wasn’t effective. What did I get wrong?

Looking back at my main themes, 4 of the 6 were about working with other people in some way. I worked with other people to develop a structure where I was working with other people but still felt like I was mostly working by myself. Was there something specific about working together, about collaboration maybe, that I’d missed? I wanted to check in with the original participants; maybe I’d misunderstood or misrepresented them.

I knew re-interviewing 30 people was overly ambitious, so I contacted 16 of them, assuming some would say no. But everyone agreed! Again, there were people from 5 countries, but I didn’t look at other demographic data because it wasn’t a formal research project this time.

What did people think?

My findings did resonate. Everyone definitely agreed that working with other people and having support from management is vital for UX work – it can’t be done in isolation. They had some good things to say about the importance of collaborating with your colleagues, not just at the research stage but during data analysis and the rest of the process, so I want to share some of those:

No one person in the library ever has the full picture around an issue. And so the more that you can gather people together to share those perspectives, the fuller picture you’re going to have. And that is really key for the success of any sort of project.

[When people are in the room] it’s more of a conversation and people are more open. I feel like sometimes whenever it’s just a recommendation list people get really hung up on whether that specific recommendation is feasible in their context, not why does the need for that recommendation exist, what’s the problem that’s been identified.

Any sort of group work definitely seems to work a lot better and get more staff buy-in and more interest; people want to know what’s happening with the outcomes.

The findings resonated in another way: a lot of people I spoke to said that they were relieved to read that other people were struggling with UX work.

It was really affirming and helpful to read through those findings and to understand that there are perhaps some external factors that were impacting my ability to be effective; it wasn’t necessarily just me.

A number of people expressed that they were happy to realize “it’s not just me.”

There were two people who I’d been especially interested in reconnecting with to hear how things had been going. When I spoke to each of them in 2019, great ad hoc UX work had excited library management who had committed to formalizing UX in their libraries. Both people saw the formalization of a structure for UX work as a key indication of support for the work and a foundation for embedding UX into the library. Both included members from senior management in their UX groups. It had all sounded fantastic. And it sounded achievable! My library was not going to create a UX department or add UX to other job descriptions, but a committee? We could form a committee! These two were a particular inspiration when I was thinking about my own structure. But, reconnecting with them, they still felt like they were the only ones trying to make UX happen; nothing was embedded, the inclusion of senior management hadn’t helped to push anything along. They were both feeling pretty discouraged.

So that was disappointing. But I have to say that I was a little bit happy to hear that maybe I hadn’t been completely inept. That these very capable people had not been able to make it work either. I was able to have my own moment of “it’s not just me!”

But also: why couldn’t we make it work? All of us had support from management in the formation of our UX groups. All of us had a formal structure to work with other people.

Let’s start with the first part – “support from management.” What does meaningful support—useful support—look like? In the original interviews, when people talked about the importance of support from management, I asked them to describe what that looked like in concrete terms. Mostly people said things like giving the time to do the work, money or other things to use for participant incentives. It was very much focused on support for specific projects. Or it was very vague “interest in UX” or “valuing UX;” a sense of that UX work was appreciated. Which is important and good. However…

I think that meaningful support from management is a kind of collaboration. That collaboration should involve you as the UX worker getting what you need (and yes, that might be money, that might be staff time), and it also should involve management getting what they need from the UX work. The word that kept coming to me as I talked with people was “expectations.” Here’s what some participants said about expectations:

[UX is] a bit of a ‘stirring the pot’ kind of role… If you have an organization where they want a smooth pond all the time (to mix metaphors), it can be at cross-purposes.

This participant went on to say that if the expectation is that UX will confirm all the great work the library has done in a particular area, then if you do interviews and discover, for example, that underrepresented populations feel attacked by library policies, when you bring those findings back, it may not be what people in the library want to hear. Another participant talked about this same thing:

[Management] had an idea of how students did use the library and when what you find doesn’t conform with that idea, then, rather than act on it, it’s kind of sort of hidden away and forgotten about.

Understanding management expectations helps you align UX with the organization. Which can help the work feel relevant and meaningful. But often, it’s difficult to tell what management expects from UX work. Often, it seems like there are no expectations beyond a general feeling of “valuing UX.”

When UX is valued but not expected, it can be enough to create a UX group or a UX position and then never ask them to do the work or listen to what they recommend. One participant said

[I feel like] they hired me so they could check a box on a list of priorities: ‘UX – alright, we have a person here: check.’ But then: nothing.

Or when UX is valued but not expected it can be enough to ask for UX research to back up a decision that’s already been made.

[Sometimes management will ask] ‘Can you do this piece of research to try to find out how students are doing x, y, and z and why they’re doing x, y, and z?’ And we’ll go off and do it and then we’ll go back with what we’ve found and it will be very much cherry-picked what they want to implement and what they don’t want to implement.

Or, when UX is valued but not expected, the organization says all the right things but no action follows. All of these are tricky because how do you advocate for UX when everyone already seems to be on your side? Said one participant:

It’s much better if people say that they don’t understand or don’t agree or don’t think it’s a good idea because then we can talk about it. We can’t have a discussion if you’re pretending to agree with me.

The library valuing UX is really important. But there has to be more.

In my original research paper I talked about “direction” from management but I don’t think that was enough. Direction is important and certainly a lot of people talked about how a lack of direction impacted them. How I phrased it in the article was a feeling of: “If it doesn’t matter what I do, then what I do doesn’t matter.” But I think direction without a sense of expectation is almost as unhelpful: “If it doesn’t matter whether I’ve done anything, then what I do still doesn’t matter.”

OK, let’s look at where it works, because it is working in some libraries!

UX is part of the strategy. These are the things the [library] wants to achieve; we want UX research to feed into these changes that we want to make.

The Dean has said ‘UX is important… we’re going to make this department, we’re going to give them money and we’re going to listen to them.’

Our colleagues can see that okay, we are forming this group to help you do UX work, we have it in the strategic plan, we are communicating around these things—there’s a message that this is a preferred way of developing library services.

There is a sense of expectation here, that UX is how work is done, how decisions are made. UX isn’t just a thing we like, it’s a thing we DO.

So, looking back, I had support from management, but it didn’t feel like a collaboration and I don’t think there were any particular expectations. However, it seems reasonable to assume that explicitly adding UX to my job and creating a UX committee indicates a certain level of support for UX in the library. It feels like it comes with expectations. So maybe you don’t know that you don’t have useful management support until you realize you don’t have useful management support.

What about the working with people part? A couple of participants said this about their own UX groups:

My hope is that I get more people on the staff thinking in UX ways…. Doing UX work in their own areas sort of organically would be my end goal, with me as a resource for ideas or methods or help, collaboration.

I wanted them to come along feeling enthused about it and knowing about within their area of expertise, or the area of work that they have, that there’s things that they want to investigate.

Those participants went on to say that this hadn’t really worked out yet. This was my experience too; I had similar expectations for my UX Committee and it hasn’t happened. But I know I haven’t clearly articulated those expectations with my colleagues because I’m worried about overloading people; I don’t want to ask too much of them. Other people voiced similar feelings:

Making another committee or making another group… is work and everybody’s already on 5 different committees or groups

They were really excited about it [UX] but it quickly died a death. And I think it’s probably more to do with their day-to-day and their workloads.

Working with people is super important. But if their workloads dictate that there are 7 other priorities before they get to UX work, that’s going to affect how collaborative the work can be.

So, support from management is important but you need to have the right kind of support and it’s hard to know if you actually have that, and working with colleagues is important but you probably have very little control over how they prioritize UX work. So, how do we structure our work to set ourselves up for success?

I think this participant nails it:

Recipes don’t work on people; it’s so frustrating! [laughs] Because that’s what I really want. I want this recipe that says do this, this, and that and then it works.

But there is no recipe, no magic structure or set of supports. People. It’s… people. In one of the keynotes at the very first UXLibs conference, Matthew Reidsma told us: the library is people all the way down. UX work, too, is people all the way down.

That feeling of relief that I heard over and over from the people I talked to: “It’s not just me!” That’s as close to a generalizable finding as I’ve got: It’s not just you.

It’s not just you:

  • If things are not going well, there are likely lots of other elements at play. It doesn’t mean that you are bad at this work.
  • If things are going well, there are likely lots of other elements at play. It’s doesn’t mean that are you are great at this work. (It doesn’t mean you’re not great! But your ability to be great doesn’t happen in a vacuum.)

It’s not just you: UX work does not happen – cannot happen – in isolation. You need other people to help you. If it’s not working, it’s likely because you’re not getting the help you need. If it is working, it’s likely because you are getting the help you need.

It’s not just you: It is not solely your responsibility to improve the user experience in your library, even if you’re the only one in the organization who has it in your title. Or your job description. You cannot fix a library by yourself. It’s not that you’re doing it wrong or that you’re bad at your job. Lots of capable, talented people cannot get this work done in their libraries. I know this because some of them have changed jobs and gone on to do really great, impactful UX work in other libraries. It wasn’t just them. It’s not just you.

It’s not just you: There are a lot of feelings in this work UX is wonderful and exciting and inspiring AND FUN when you can do it well. And I think it’s particularly dispiriting when it fails; when you see what a difference a few changes could make and you can’t make those changes happen, for whatever reason. It can feel like you’ve let down the users who gave you their time and their thoughts, their feelings. It can feel like you’ve let down your colleagues who engaged with the project and wanted to make improvements too. And it can feel like you’ve wasted your own time, your own energy and enthusiasm, when everything you’ve done is just ignored. It’s so very easy to take it personally when we fail, because when we succeed it feels so good. As one participant said:

It could be great, so it’s that much further to fall.

This is another reason why it’s so important that UX work is a collaboration. Because the failure should not feel personal. And the success should not feel personal. And when it feels like you’re doing it alone, it’s always going to feel personal. One of the people I spoke to who shares UX responsibility with a colleague said

It’s such a joy to have another person. I have such a luxury – a person to do this work with.

It lets her know right away that it’s not just her, that her colleague has the same struggles that she has.She had what I found to be pretty inspiring advice, given that she’s been doing this work for a long time in a library that doesn’t always support and appreciate the work:

I’ve also adopted a mindset that this one thing didn’t work this time but that doesn’t mean it’s not going to work next time. I’m really able to compartmentalize and say ‘oh, we tried this little strategy and it didn’t work for this project, but we can try it again with different people and a different project and a different set of external factors and it could maybe work.’ And that, to me, kind of keeps it fresh.

What really strikes me about that is the emphasis that context is so very important and that it’s a shifting thing. So maybe what I got wrong in my original project wasn’t the analysis or the themes. Maybe the entire premise was flawed.

Because there is no structure or set of supports that will set us all up for success. We all work in different contexts. We all work with different people. What works for someone else might not work for you. What works for you this year might not work for you next year. Context changes. People change.

So my new takeaways aren’t about structures or supports. They’re a little more personal, and a little more in my control:

  • As that participant advises: Keep trying things. Not in a cult of productivity “keep going no matter what!” kind of a way. Take breaks when you need to, beware of burnout, don’t bang your head against the same wall all the time. But for me, I can become so afraid of wasting effort that I do stop trying. So I will try different things, I will try the same things in different ways. I will keep trying.
  • So many people I talked to said variations on “Concentrate on where you can be successful.” One person said “There has to be a prioritization anyway. So that becomes one of the aspects when we do that prioritization: Where can we be successful? Where should we put our time and efforts? To me, it makes more sense to do it where it’s going to be easier.” I also like it as “Figure out what makes you happy and do more of that. Figure out what makes you miserable and do less of that!”
  • Celebrate every win; keep track of them for yourself. Remind your future self that they can do this. And share your wins with your colleagues. One participant said “It helps to see someone else be successful. It helps to have a positive example somewhere else… [Colleagues] can see [UX] is a viable way of doing something and achieving something.”
  • And finally: Reach out to other UX folks. Our jobs don’t always give us what we need. One participant said: “I miss, I can’t even say that I miss it because I’m not sure I’ve ever had really good management, sadly…. There are good managers in the world – you hear about them – and somehow they inspire and push and lift their employees.”

A lot of us are seeking community. I know this came up at last year’s conference and a sub-Reddit was formed but that hasn’t seen much use. But you can think a little smaller. There are 2 presentations at this conference about regional UX communities – one in northern England and one in the Netherlands. Even smaller scale is wonderful. A UX person at another library in my city reached to me when she started her position, and we started meeting over Teams once a month to chat about what we were doing. We’ve recently expanded that to 3 other people. It takes a little organization and coordination – it takes more than just putting a structure in place – but it’s so worth it. Have you met someone great here? Stay connected! Check in with each other. If you can’t find anyone, please, get in touch with me and I will find you people.

Honestly, the absolute best part of both of these projects has been talking to other UX people. We’re great. Collectively, individually, we are just lovely. So talk to each other. Help each other out. “Inspire and push and lift” each other. It’s not just you.

That would be a lovely way to end, but I do want to take a moment to sum up.

I hoped my original project would point to some structures and supports that would help us be able to do great UX work. And although the themes that came through in that project bear out – essentially: don’t do the work by yourself, and have support from library management – upon reflection, they aren’t sufficient. And they aren’t necessarily things you can control. You can advocate to your management team, but you can’t make them give you direction or priorities or have expectations for you. You can try to encourage collaborative work with your colleagues, but you can’t make them be engaged, particularly if they’re overwhelmed with their own workloads.

Although structure is not sufficient for success, there can be structural impediments to success. Most of us will come up against those at some point. So, particularly after a conference where you’re hearing from so many fabulous people doing amazing things, please do remember that what works for someone else may not work in your context. With your people.

If you’re struggling to make changes or to do the work at all: it’s not just you. A lot of us are feeling a bit lonely trying to do amazing things in our libraries and not quite getting there. Keep trying. If things are grim, do the easier things, do the things that make you happy. Celebrate your wins, no matter how small! Share them with your colleagues, share them with us. Reach out. It’s not just you.

Web Librarians Who Do UX: Access presentation

This is the text (approximately) of my presentation from the virtual Access conference on Oct.19, 2020, “Web librarians who do UX: We are so sad, we are so very very sad.”

Last year, I was doing interviews with library people who do User Experience work and noticed that people who were primarily focused on the web had the most negative comments and fewest positive comments overall. It made me think of the song from Scott Pilgrim—the comic and the movie—“I am so sad, I am so very very sad.”

So there’s the title.  And I’m saying “We are so sad” because I am also a web person who does UX work. And a lot of what I heard seemed familiar.

I want to say that although the title and the visuals are based around a comic and comic book movie, I’m not trying to be flip. A lot of the people who I talked to were very open about being unhappy. Not everyone was unhappy. But, there was a lot in common among the people who said they were struggling and those who were pretty positive. Here are some quotes from people who were generally pretty positive :

  • “How much can I do that no one will block me from doing?”
  • “Why am I really here then, if I’m just moving things around the page?”
  •  [I keep feedback] “for promotion purposes but also not-being-sad purposes.”

And from the not-so-positive :

  • “You have all the people who have their own personal opinions… and you’re like “you’re violating every good norm of website development”… they think their opinion is just as good as anyone else’s opinion. … That can definitely demoralize you.”
  • “I bounce back and forth between, for my own sanity’s sake, needing to be apathetic about it, saying ‘I can’t change this therefore I can’t be stressed about it’, and also on the other hand, caring that we have crappy stuff out there and wanting to improve it.”
  • “It is what it is. There’s lots of other things to be disappointed by.”

Heartbreaking, right? So why is this the case?

First  a tiny bit of background on the research project. The aim of the project was to look at how UX work is structured and supported in academic libraries and then to examine those supports within the context of the structures. I did hour-long semi-structured interviews with 30 people in academic libraries from 5 countries (Canada, the US, the UK, Sweden, and Norway). These were library workers who do UX, so not necessarily librarians, and not necessarily people in UX positions. The people I’m talking about today focus mostly on the web in their jobs.

The frustrations of web folks were particularly  striking because I didn’t ask a question about frustrations; I asked what supports were helpful to them and what would be helpful. Admittedly, asking “what would be helpful” is going to bring up deficiencies, but I didn’t ask what supports were missing or what they found frustrating in their work. And again, the web folks talked more about frustrations and difficulties than participants who didn’t have a web focus.

So let’s dig in a bit. Why, specifically, are we so sad?

First off, we have a tendency to want to think big! Do more!

  • “That’s what motivates me—the opportunity to really sit down, talk, observe, have a conversation with our users, how they approach the website, how they approach the research process, how they approach finding out about our services and how we in turn can better highlight our resources, how we can better highlight our collections, our services.”
  •  “If I see people struggling with things, I want to make them better.”
  • “I don’t want UX to be just a website thing. I don’t want people to think of it ‘oh, it’s just a web thing.’ I want it to be in everything.”
  • “I just see lots of potential all the time. I see potential everywhere, the whole library. I see things we could do that would enhance things.”

That doesn’t sound sad. There’s energy and excitement in those words!

But contrast it with:

  • “Why am I really here then, if I’m just moving things around the page? I’m trying to get deeper. I’m trying to get a better understanding. It’s not just a matter of moving things around.”

Web people who do UX are, I think, well positioned—and perhaps uniquely positioned—to see big picture problems across the library. One participant told me they found that users were confused about the Circulation section of the website because there were 18 different policies underlying it; they could rewrite the web content but couldn’t do anything about the underlying spaghetti of policies. Another said that users found the floor maps confusing but the maps reflected the language used on the library’s signage; they could put clear language on the website’s floor maps but couldn’t do anything about the signage in the building.

So we see these problems and naturally want to solve them. We get excited about the potential to make more things better. And we chafe against having to think smaller and do less.

Which brings us to: lack of authority. Lack of authority often comes up around those larger library issues. One participant put it this way:

  • “The UX work is actually informing something else to happen. Whether that’s a space being reorganized or a webpage being redesigned—the UX work is informing this other work. Right? So it would be easier for me to do the UX work if I could actually do the work that it’s informing.”
  • Another person was even having problems at the research stage: [I’d like to] “have the authority and freedom to actively engage with users.”
  • And someone else, in talking specifically about their web work said: “Nobody tries to stop me.” The implication being that people try to stop them when they do other things.

But for many participants there was a lack of authority even when dealing with the library website:

  • “The web team doesn’t feel like they can really make changes without consult, consult, consult with everybody even though – even if, and even though – the web team has web expertise.”
  •  “Just because I’m our internal expert on this stuff doesn’t mean I can persuade everybody.”
  • “There’s too much of a sense that these things have to be decided by consensus”
  • “Everyone feels… like they should have the right to declare how databases should work, how links should be configured, things like that.”
  • [Each library unit feels] “they have the right to do whatever they want with their content and their presentation. … I’m not their boss and they realize that.  I’m happy to draw up more guidelines and stuff like that but if I’m not allowed to enforce that… [it’s] hard to keep things together when you just have to go hat in hand to people and say ‘pretty please, stop breaking the guidelines.’”

One participant described how having no authority for the one thing they were responsible for made them feel: “Of course that has stymied my initiative, not to mention my disposition. My purpose even.”

Another frustration that came through was resistance from colleagues. A few comments have already touched on colleagues ignoring expertise but resistance comes through in other ways

  • One participant described how they always approach a particular department: [I’m] “treading very slowly and carefully and choosing my words very carefully”
  • Another said: “Are they deliberately killing the idea but trying to avoid being disagreeable about it but just letting it die from attrition, or do they really actually mean it when they say they agree with the idea in principle but just don’t want to be bothered to follow through? I don’t know – I can’t tell the difference.”

These are things participants were told by their colleagues:

  • A manager said that “staff felt unfairly targeted” by their work
  • In opposing to changes to the website: “We have to keep it this way because we teach it this way”
  • And similarly, “It’s our job to teach people how to use, not our job to make it easier to use.”

So, not surprisingly, these kinds of things make us feel isolated. Feelings of isolation come through in a few ways. Some participants felt they were completely on their own when deciding where to focus their attention. This is one participant talking about being new in their position:

  • “I remember asking for, if there were any focuses they wanted to focus on… they said ‘no, there’s nothing. We don’t have any direction for you to go in.”

That lack of direction is often coupled with not having colleagues who do the same work:

  • “It’s really me and up to me to figure out where to focus my attention by myself. So sometimes having someone to bounce ideas off of and talk things through with… would be nice.”

And when no one else does what you do:

  • “Sometimes that’s a barrier, if I’m the ‘expert’ and other people don’t really know what I’m talking about.”

So, isolation, having to think small and do less, resistance from colleagues, and lack of authority. Yeah, no wonder we feel a bit sad.

What are my take-aways?

We need to find our people. UX folks who worked with groups of colleagues were more positive about their work. However, people who tried to do UX work with non-UX committees were even more negative than people who had no group at all. So we can’t just look for any people, they have to be the right people.

I wrote an article about the larger project that was published in Weave earlier this month and in it, one of my recommendations was to try to move beyond the website. But I want to say here that moving beyond the web is not a panacea. I talked to someone who had great success in UX for the website and other digital projects. They wanted to embed UX throughout the library and they had management support to do it. But after continued resistance from colleagues, they realized they couldn’t make it work, and decided to move to a completely different area of the library. Which brings me to my next point.

Advocacy is important, absolutely, but when we’re not getting buy-in, we need look at next steps: do we need to change our tactics? Would it be better to have someone else advocate on our behalf? Do we need to wait for a change of leadership? Or, as a few participants said, a few retirements? At a certain point, do we give up, or do we get out? Because advocacy doesn’t always work. And if it’s not working , we shouldn’t keep banging our heads against the post, right?

Ultimately , I think we need to be clear about authority.

We need to understand how authority works in our own library. Not just who can block us and who can help, but are there organizational structures that confer some authority? Is it better to chair a committee or a working group? For example.

Then, we need a clear understanding of what our own authority is within our organization. Maybe we underestimate the authority we have. Maybe not. But we need to be clear before we get to the next part.

Which is: we need to clearly understand our own tolerance for doing work that will never be acted on. The report that sits in a drawer. If our tolerance is low, if it’s upsetting to have our work ignored, then we need to stick very closely to our own sphere of authority. We have to dream within that sphere or burn out.

“Dream small or burn out” is an exceptionally grim note to end on.  But these frustrations are largely beyond one person’s control. If you’re feeling so very very sad because of some of these things, IT’S NOT JUST YOU. The fact that these issues were common to web folks, regardless of how they seemed to feel about their work, suggests that these positions are prone to these kinds of frustrations.

I wish I had some ideas for how to fix it! If you do,  please add them to the chat, tweet at me, email me (see contact info). I’ll gather it all in a blog post so it’s all in one spot. Thanks.

Redesigning our Subject Guides: Student-First and Staff-Friendly

I presented about our Web Committee’s redesign project at Access 2016 in Fredericton, NB on October 5, 2016. We started doing user research for the project in October 2015 and launched the new guides in June 2016 so it took a while, but I’m really proud of the process we followed. Below is a reasonable facsimile of what I said at Access. (UPDATE: here’s the video of the session)

Our existing subject guides were built in 2011 as a custom content type in Drupal and they were based on the tabbed approach of LibGuides. Unlike LibGuides, tab labels were hard-coded; you didn’t have to use all of them but you could only choose from this specific set of tabs. And requests for more tabs kept coming. It felt a bit arbitrary to say no to tab 16 after agreeing to tab 15.

desktop-unfriendly

We knew the guides weren’t very mobile-friendly but they really were no longer desktop-friendly either. So we decided we needed a redesign.

Rather than figure out how to shoe-horn this existing content into a new design, we decided we’d take a step back and do some user research to see what the user needs were for subject guides. We do user testing fairly regularly, but this ended up being the biggest user research project we’ve done.

  • Student user research:
    • We did some guerrilla-style user research in the library lobby with 11 students: we showed them our existing guide and a model used at another library and asked a couple of quick questions to give us a sense of what we needed to explore further
    • I did 10 in-depth interviews with undergraduate students and 7 in-depth interviews with grad students. There were some questions related to subject guides, but also general questions about their research process: how they got started, what they do when they get stuck. When I talked to the grad students, I asked if they were TAs and if they were, I asked some extra questions about their perspectives on their students’ research and needs around things like subject guides.
    • One of the big takeaways from the research with students is likely what you would expect: they want to be able to find what they need quickly. Below is all of the content from a single subject guide and the highlighted bits are what students are mostly looking for in a guide: databases, citation information, and contact information for a librarian or subject specialist. It’s a tiny amount in a sea of content.guide-overload

I assumed that staff made guides like this for students; they put all that information in, even though there’s no way students are going to read it all. That assumption comes with a bit of an obnoxious eye roll: staff clearly don’t understand users like I understand users or they wouldn’t create all this content.  Well, we did some user research with our staff, and turns out I didn’t really understand staff as a user group.

  • Staff user research
    • We did a survey of staff to get a sense of how they use guides, what’s important to them, target audience, pain points – all at a high level
    • Then we did focus groups to probe some of these things more deeply
    • Biggest takeaway from the research with staff is that guides are most important for their teaching and for helping their colleagues on the reference desk when students have questions. Students themselves are not the primary target audience. I found this surprising.

We analyzed all of the user research, looked at our web analytics and came up with a set of design criteria based on everything we’d learned. But we still had this issue that staff wanted all the things, preferably on one page and students wanted quick access to a small number of resources. We were definitely tempted to focus exclusively on students but about 14% of subject guide use comes from staff computers, so they’re a significant user group. We felt it was important to come up with a design that would also be useful for them. In Web Committee, we try to make things “intuitive for students and learn-able for staff.” Student-first but staff-friendly.

Since the guides seemed to have these two distinct user groups, we thought maybe we need two versions of subject guides. And that’s what we did; we made a quick guide primarily for students, and a detailed guide primarily for staff.

We created mockups of two kinds of guides based on our design criteria. Then we did user tests of the mockups with students, iterating the designs a few times as we saw things that didn’t work. We ended up testing with a total of 17 students.

Once we felt confident that the guides worked well for students, we presented the designs to staff and again met with them in small groups to discuss. Reaction was quite positive. We had included a lot of direct quotations from students in our presentation and staff seemed to appreciate that we’d based our design decisions on what students had told us. No design changes came out of our consultations with staff; they had a lot of questions about how they would fit their content into the design, but they didn’t have any issues with the design itself. So we built the new guide content types in Drupal and created documentation with how-tos and best practices based on our research. We opened the new guides for editing on June 13, which was great because it gave staff most of the summer to work on their new guides.

Quick Guide

quick-guide

The first of the two guides is the Quick Guide, aimed at students. I described it to staff as the guide that would help a student who has a paper due tomorrow and is starting after the reference desk has closed for the day.

  • Hard limit of 5 Key Resources
  • Can have fewer than 5, but you can’t have more.
  • One of the students we talked to said: “When you have less information you focus more on something that you want to find; when you have a lot of information you start to panic: “Which one should I do? This one? Oh wait.” And then you start to forget what you’re looking for.” She’s describing basic information overload, but it’s nice to hear it in a student’s own words.
  • Some students still found this overwhelming, so we put a 160-character limit on annotations.
  • We recommend that databases feature prominently on this list, based on what students told us and our web analytics: Databases are selected 3x more than any other resource in subject guides
  • We also recommend not linking to encyclopedias and dictionaries. Encyclopedias and Dictionaries were very prominent on the tabbed Subject Guides but they really aren’t big draws for students (student quotations from user research: “If someone was to give this to me, I’d be like, yeah, I see encyclopedias, I see dictionaries… I’m not really interested in doing any of these, or looking through this, uh, I’m outta here.”)
  • Related Subject Guides and General Research Help Guides
  • Link to Detailed Guide if people want more information on the same subject. THERE DOES NOT HAVE TO BE A DETAILED GUIDE.
  • Added benefit of the 2-version approach is that staff can use existing tabbed guides as the “Detailed Guides” until they are removed in Sept.2017. I think part of the reason we didn’t feel much pushback was that people didn’t have to redo all of their guides right away; there was this transition time.

Detailed Guide

detailed-guide

  • From a design point of view, the Detailed Guide is simpler than the Quick Guide. Accordions instead of tabs
    • Mobile-friendly
    • Students all saw all the accordions. Not all students saw the tabs (that’s a problem people have found in usability testing of LibGuides too)
  • Default of 5 accordions for the same reasons that Key Resources were limited to 5 – trying to avoid information overload – but because target audience is staff and not students, they can ask for additional accordions. We wanted there to be a small barrier to filling up the page, so here’s someone adding the 5th accordion, and once they add that 5th section the “Add another item” button is disabled and they have to ask us to create additional accordions. add-accordion
  • There’s now flexibility in both the labels and the content. Staff can put as much content as they want within the accordion – text, images, video, whatever – but we do ask them to be concise and keep in mind that students have limited time. I really like this student’s take and made sure to include this quotation in our presentation to staff as well as in our documentation:
    • When I come across something… I’ll skim through it and if I don’t see anything there that’s immediately helpful to me, it’s a waste of my time and I need to go do something else that is actually going to be helpful to me .

And speaking of time, thank you for yours.