This is a version of the content I presented as part of my workshop at UXLibs IV in Sheffield on June 6. Clearly, I talked way too much.
This is very much an exploratory workshop. I’m going to talk for a bit about an idea or concept and then you’ll have time to reflect and explore how that might apply in your own library. Then I’ll talk some more, you’ll reflect some more, and so on. We could easily do a lot of “think, pair, share” but I know that model doesn’t work for everyone – some of you need quiet time to think, some of you need to talk to think, and there are people in the middle. I’d like you to be able to think and explore in the way you need to. So, if you prefer to talk through your ideas with other people could you write a big T on a sticky and stick it on yourself? And if you prefer to think quietly to yourself, could you write a big Q on a sticky and put it on? If you don’t care, just label yourself a talker. When we get to the time when we’re reflecting and exploring, if you’re a talker, please seek out other talkers and let the quiet folks do their own thing. You can also change your letters as we go.
On to friction!
What do I mean when I talk about friction? Some people define friction in UX as anything that frustrates you, but I think of it more as something that slows you down – like in physics. You have an object sliding down an incline – more friction makes it go slower. And yes, heat or frustration can build up, but I am primarily talking about the slowing effect.
When people talk about friction in UX, it’s usually in the context of wanting to remove it. Because we don’t want to slow people down unnecessarily; we want to help them do what they need to do with the least amount of fuss. But often libraries do slow people down. We see buildings with a jumble of signage. We see websites with a lot of text and jargon. We have a lot of processes with way too many steps.
And I think that’s why many of us are drawn to UX. We see things like this and we want make things easier for our users. Some of you may be familiar with Steve Krug. Don’t Make Me Think is a classic in web usability. Essentially, Krug says: People don’t want to think about your website, they just want to do what they need to do. When you go to the library website, you shouldn’t have to think too hard to find the hours. When you come into the library, you shouldn’t have to think too hard to find a toilet. It should be clear, it should be easy. I love Don’t Make Me Think.
But, today, I want to explore the idea that there may be times when we do want our users to think.
An example, though not from libraries. Some of you might remember from earlier this year, an alert went out to people in Hawaii. “Ballistic missile threat inbound to Hawaii. Seek immediate shelter. This is not a drill.” But it was a drill.
A shot of the screen the employee who made the mistake saw made the rounds almost immediately.
You can definitely argue that there was too much friction on that screen. But, as many argued in the days that followed, there was clearly not enough friction in the design of the system to prevent errors. It seemed so obvious that people designed a bunch “are you sure” pop-ups that they thought could have helped slow down the employee. To help make him think.
Now, what on earth does this have to do with libraries? Our users are not going to be sending missile alerts from our library catalogues. But have a look at this example:
I do a search in Summon for user experience friction, limited to journal articles, full text, and in the last three years. I look at the results and see one from Journal of Documentation. What happens if I click that link? Let’s assume I notice this: Search within Journal of Documentation. I don’t want to do that. Let’s clear and get back to my results. I didn’t want to clear everything! Okay, I’ll use the back button. Got back to search within the journal, so back again. I just want to get back to my original results. But they’re gone. Once I click that link, I can’t go back. And okay, losing your search isn’t the same as triggering a missile alert. But it’s not great. This definitely needs a little more friction before a single click wipes out my search.
So friction can come in the form of preventing people from making mistakes. Slow them down, maybe give them some extra information, so they don’t do something they don’t mean to do. But friction can have other
At the Interaction17 conference, Christina Xu talked about friction in UX design in China. While she was working there, she found that sometimes she had to engage in a conversation by phone or chat with someone at a business before she could complete an online transaction. Even when she used the equivalent of Uber in China, called Didi, her driver would call to confirm her location. She found this weird but realized that this kind of friction was being used to establish accountability or trust; to help build a relationship. In an academic library context, maybe a student has to contact a subject liaison as a step in their research assignment. That could make it more likely that the student contacts their liaison again. My local public library makes users come in to a branch at least once a year to renew their library card. So friction can definitely be in the physical world as well.
(At this point, I asked workshop participants to think of their own libraries and where there may be spaces or services or interfaces where users could be helped by being slowed down a bit. They could brainstorm with others or think on their own, and they wrote their ideas down on post-its.)
It can be tricky to think about slowing users down, when we usually try to streamline things for them. So, I’m going to introduce another way to add friction in your library without slowing down your users. Instead, you can add friction for library staff.
At my library, we redesigned our online subject guides to try to make them less overwhelming for students. We moved from a tabbed design to accordions. In our user testing of this design, we found that more than 5 accordions was a little much for students to quickly scan. So, on the back end we built in a little barrier:
The button to add more section is disabled when you get to your 5th accordion. Staff are allowed to have more but they have to make a request. And we’ve only had one person make requests for more accordions. That little bit of friction in the back-end design has been enough to keep people to 5 accordions which, ultimately, makes a better front-end design for our users.
On the physical side, at my library, we used to make students bring us the call number of books they wanted from our Reserves Room (a closed stacks area). If students came to the desk with just a title they were sent away to look up the call number. Now, we have a computer at the Reserves Desk and staff are encouraged to help students find what they need. They don’t have to, but since the computer is right there, they look like jerks if they don’t. Adding friction for staff can be a way of aligning staff work with user needs. You want to make it easy for staff to act in ways that support users. Or, to put it another way, you want to make it difficult for staff to act in ways that don’t support users.
(At this point, I again asked people to think about adding friction for staff in their libraries in order to encourage user-centred behaviours—though no electric shocks or trap doors, please. Again, they wrote their ideas on post-its.)
We’re going to change gears again and think about adding friction to improve inclusion. Many of my examples and ideas around this come from the wonderful book Design for Real Life by Eric Meyer and Sara Wachter-Boettcher. The book is about how a lot of design assumes a pretty narrow range of demographics or life experience. One of the driving forces behind the book was Eric’s experience of getting a Year in Review ad from Facebook, full of happy clip-art people dancing around a picture of his young daughter who had died from brain cancer that year. Definitely not a year for dancing. Eric doesn’t say this directly, but this kind of thing tells a user “our product, our service, it’s not for you.” And I don’t think we ever want to tell our users that the library is not for them.
So where does friction come in? Well, sometimes trying to cut down on friction in processes and interfaces can create a design or service that leaves out certain people. Maggie Delano describes using the period tracker Glow, that only gives these three options for why you’d want to track your period:
- Avoiding pregnancy
- Trying to conceive
- Fertility treatments.
Maggie says, “It’s telling women that the only women worth designing technology for are those women who are capable of conceiving and who are not only in a relationship, but … in a sexual relationship with someone who can potentially get them pregnant.” This left out Maggie and it leaves out a lot of people with periods. But three options fit so nicely on the screen! Adding more options is going to create complexity, it’s going to slow things down. But it’s also going to be more inclusive.
Another example is the radio button for selecting gender on a form. Even when it’s expanded beyond a binary choice, it’s problematic:

Do you really want to make people self-identify as “other”? Is “Prefer not to say” the safest choice? But what if you’re actually quite happy to say but you’re not represented here? I would question whether you really need this information. But if you do, make it a free form question for everyone. Don’t just make people who don’t fit the binary write in their answer; give everyone that same friction of choosing what to enter. And explain what the information will be used for, so someone doesn’t get outed unexpectedly. Yes, this will make your form wordier. Yes, it will slow people down. But this friction is worth it to make sure that you’re not telling groups of your users that the library is not for them.
(At this point, I asked participants to think about where in their libraries they could add a little friction—on the user side or on the staff side—that could help with inclusion; that could implicitly or explicitly let a group of users know that they are welcome. Again, ideas were captured on post-its. After this, participants posted all of their ideas and spent time looking at others’ ideas.)
Now I want to talk for a little bit about friction and user research.
Remember that Hawaii missile warning and people saying that there should have been an “are you sure?” pop-up? It seems like a no-brainer. We see them everywhere for even trivial things. But because we see them everywhere for even trivial things, they don’t always work. In a book about the use of technology in medicine and hospitals, Robert Wachter reports that at one hospital, of 350,000 medication orders per month, pharmacists received pop-up alerts on nearly half of them (The Digital Doctor: Hope, Hype, and Harm at the Dawn of Medicine’s Computer Age). That’s a pop-up alert about every 18 seconds. Pharmacists, unsurprisingly, learned to click past those alerts without even looking at them. You can’t just add friction, you have to test it and test it in your users’ context. Is the friction creating a useful pause, or is it just frustrating?
Another aspect of friction and user research is what happens when users bring friction with them. Design for Real Life has a whole chapter on what they call stress cases – not edge cases but stress cases – and how stress depletes our cognitive resources. A stressed brain simply does not function as well. And for those of us in academic libraries, we can be certain that our users are coming to us stressed.
A 2016 survey of students in universities in my home province of Ontario found that 65% had experienced overwhelming anxiety in the past 12 months. 65% had experienced overwhelming anxiety. Some libraries are trying to include resources on their websites to help stressed students.
But how can you make sure your sites and services are usable by people under stress? Users who agree to participate in research or testing are generally not those who are experiencing overwhelming anxiety. And certainly you don’t want to create overwhelming anxiety for your participants! But you can generate a little bit of cognitive stress by having them remember a sequence of 8 letters and numbers or a sequence of 8 symbols, or you can have some conversational noise in the background. These fairly simple activities can mimic a stressed brain and let you know if your designs work okay for people under some stress.
Although we generally want UX in libraries to be smooth and easy, there may be times when we want to slow people down a bit. To give them a bit of space to think: to help them avoid mistakes, to help them make connections. Or we might want to slow down our library staff to help them act in ways that serve users well. There might be ways friction can help our libraries be more inclusive, more welcoming. And we might want to add friction to our user research in order to mimic some of the stress our users are under when they come to us. We definitely should test any friction we add to our services, spaces or interfaces to make sure that we’re not actually creating frustration instead of that useful pause.
(Before people left the workshop, I promised to share the ideas generated in both workshops. There were so many post-its! But here are all of the ideas generated by the participants.)
3 thoughts on “UXLibs Workshop: Adding Useful Friction to Library UX”