Issue 28, 2015-04-15

User Experience is a Social Justice Issue

When we’re building services for people, we often have a lot more practice seeing from the computer’s point of view than seeing from another person’s point of view. The author asks the library technology community to consider several case studies in this problem, including their root causes, and the negative impact of this problem on achieving our mission as library technologists. The author then recommends specific actions that we, as individual contributors and organizations, can take to increase our empathy and improve the user experience we provide to patrons.

by Sumana Harihareswara

Editors’ note: The content of this article was originally presented as a keynote address at the Code4Lib 2014 annual conference under the title, “UX Is A Social Justice Issue.” The editors have adapted the speech for print, and the author has provided a new introduction and conclusion reflecting on the state of user experience design one year later.


The Code4Lib community asked me to give one of the keynote speeches at Code4Lib 2014 while I was the community manager for the Wikimedia Foundation’s open source projects and an advisor to the Ada Initiative. My Wikimedia expertise intersects with the interests of the Code4Lib community, as Wikimedia — like many libraries and other cultural institutions — aims to empower patrons with access to information.

Before I worked in open source, I worked in customer service. I saw first-hand how design flaws (in architecture, signage, and websites) could frustrate and drive away customers and make more work for me. Every time I participated in an open source project — AltLaw, GNOME, MediaWiki, and more — I’ve brought that experience with me. I found it particularly striking that small changes on Wikipedia could cause large changes in user behavior, as I discuss in this essay, which is adapted from my keynote speech.

This issue goes beyond software, as I explain with the healthcare and banking examples. The spark that caused me to write the speech was reading Professor Lisa J. Servon’s piece in The Atlantic about the usability of storefront check cashing services; I saw a pattern where poor user experience repels people from crucial and empowering services, and decided, in a flash of anger and inspiration, to write “User Experience is a Human Rights Issue.”

I am following in the steps of Jeremy Prevost and Bess Sadler and Mark Matienzo, among others, in their previous Code4Lib presentations and writings about design and emotion [1]. In adapting my speech for this article, I toned down the title to “User Experience is a Social Justice Issue,” but the narrative is largely the same. I hope you find it thought-provoking.

The Last Mile Problem

The largest hurdles we as technologists face are choosing to make the right things in the first place and choosing to make them usable. In the 1990’s, telecommunications companies laid down a lot of fiber to connect big hubs to one another, but often it took years to connect those hubs to the actual houses and schools and shops and offices, because it was expensive, or because companies were not creative enough to do it well. This is called the “last mile problem,” and I think usability has a similar problem. We have to be creative and disciplined enough to actually provide services in a way that people can use them.

When we’re building services for people, we often have a lot more practice seeing things from the computer’s point of view or from the data’s point of view than from another person’s point of view. In tech, we understand how to build arteries better than we understand how to build capillaries. Personally, I think capillaries are more interesting than arteries. Maybe it’s just personal temperament, but I like all the little surprising details of how people end up experiencing the ripple effects of big new systems, and how users actually interact with the user interface of a service, especially ones that we don’t really think of as having a user interface. Like taxes, or healthcare, or hotels. All these big systems end in little capillaries, where people exchange information or get healed or get whatever they need. And when those capillaries aren’t working correctly, then those people just don’t get what they need. The hubs are connected to each other, but people aren’t connected to the hubs.

Over and over, in lots of different fields, we see that bad usability makes a huge difference. When choosing between two services, people will make very different choices, depending on which service actually seems designed around the user’s needs. In March 2014, librarian Jessamyn West was in a conversation on MetaFilter about coffee machines, in particular, Keurig pod machines. These machines will only make coffee from pods manufactured by the company that makes the machines. One person said, “This convenience thing is a bit overstated.” Jessamyn’s response was:

Not that I’m not more in your camp taste-wise than the Keurig camp but I see this as a great exercise for people generally in the “other people have different priorities in life and aren’t just bad versions of you” direction. Not you [personally], just the general you. I know a lot of people for whom Keurigs solve a problem and they don’t mind the downsides. I respect that. I also know a lot of people who wouldn’t be caught dead with one and I respect that as well.

I know it’s tough to get your head around but the goal state for people with Keurigs is generally not to just have the best cup of coffee. It’s to have a coffee solution that is easy to clean up after, or that turns itself off, or that has pre-measured sizes, or that has all the brands that people like, or that makes cocoa, or that offers holiday flavors, or that you can buy at the department store, or that is easy to clean, or that can be modified to accept change, or that you can put in a place with no running water, or that descales itself, or can be put in a place without a kitchen, or that has funky modern lines, or that can make ten cups of passable coffee in five flavors (caf and decaf) in ten minutes. These things do not solve problems for me, but they solve a problem for an awful lot of people which is why these things are so popular (West 2014).

So, yes, usability makes a difference in what coffee people drink. And if you care about health, and education, and the working class, then this is actually scary, because differences in user experiences are driving people to make bad choices. I want to give you a few examples.

Banking: Payday lending and check-cashing services have sprouted up in many working-class communities. These services are often predatory or incredibly expensive, compared to traditional banking services. They do not provide a way to save and earn interest instead of paying interest.

But Lisa J. Servon, an urban policy professor at The New School, worked in a RiteCheck for four months and found that one reason people chose RiteCheck over a traditional bank was the user experience. It was the hospitality people were getting. She wrote in The Atlantic:

The glue at RiteCheck is the customer/teller relationship. I interviewed 50 RiteCheck customers after my stint as a teller and, when I asked them why they brought their business to RiteCheck instead of the major well-known bank three blocks away, they often told me stories about the things the RiteCheck tellers did for them… At RiteCheck, the tellers treated the customers as individuals and went the extra mile to assist them, perhaps in the same way that a neighborhood grocer might allow a trusted customer to run a monthly tab. On busy days, tellers regularly skipped lunch and coffee breaks in order to keep the wait times down. Ana Paula, our manager, often joined us at the window. The customer always came first and knew it (Servon 2013).

Servon believes that to attract these depositors, banks would need a better product — fee and service structures that work for them and are designed around user experience.

Ebook lending: The New York Public Library (NYPL) has been lending out e-books for years. Many people in New York City have smartphones or dedicated e-book reading devices. I think we could expect that people who are already buying e-books would be interested in borrowing them for free. But e-book borrowing rates at NYPL are abysmal. For context, across the United States, for every one hundred print books sold, somewhere from 30 to 80 e-books are sold. This calculation is from some rough numbers that some friends and I put together. It might be off, but it’s not much beyond, let’s say, 3-to-1.

Given that New York Public Library lent out about 250,000 print books every week last year, you might hope that NYPL would be lending out, let’s say, maybe 150,000 e-books a week, or lower than that, maybe 100,000. Let’s say it’s a 5-to-1 ratio – 50,000 e-books a week. But instead, it was actually much lower than that. In 2013, NYPL lent out 19,000 e-books a week. So instead of a 3-to-2, 3-to-1 ratio, it’s more like a 13-to-1 ratio.

New York Public Library has this department, NYPL Labs, which is researching this problem. NYPL Labs has broken down the e-book borrowing experience and found that it currently takes 18 separate steps for an NYPL user to borrow an e-book. I saw this diagram that was called “19 Steps of Hell.” They have been working on a project to take that down to three steps. And I would predict that this would raise e-book borrowing rates beyond this 13-to-1 print-to-e-book ratio.

Wikipedia: I have first-hand experience of this from my work at the Wikimedia Foundation, the organization behind Wikipedia. Wikimedia’s number one concern is gaining and retaining Wikipedia editors, as well as contributors to Wikidata, Wikivoyage, and so on. If we want a world in which every single human being can freely share in the sum of all human knowledge, then we need diverse perspectives editing and providing that knowledge.

We’ve found that sometimes little things in usability make a really big difference. For a subsection of a Wikipedia article, the “edit” link used to be all the way at the right side of the screen. It wasn’t obvious what that link was for, and some users thought it was the link to edit the previous section. So we moved that link to be right next to the subsection’s header. The click-through rate more than doubled. It went up by 117 percent, and that higher volume of clicks led to 8.6 percent more edits as well (Wikimedia contributors 2012).

We see the bounce-off effect where people hit the Edit button, see a form full of wikitext, the markup language that evolved with MediaWiki, and just hit the back button. Generally when newcomers see that, they worry that something’s broken, because when else would you see that kind of gibberish on a website?

To improve this user experience, we have invested in making a visual editor appropriately called the VisualEditor. You can try it right now on English Wikipedia, if you log in and turn on Beta Features in your preferences. Our hypothesis, which we’re working to prove, is that if we make the user experience better, more people, and more different kinds of people, will edit.

One last note about Wikipedia and usability: you don’t have to register to read Wikipedia. It’s just there, no paywall, no registration wall. And there are a lot of really great other open educational resources out there, OERs, that have content that readers would really find useful, maybe just as useful as Wikipedia – except they’re behind a registration wall. That just massively reduces how many people are going to see it.

Healthcare: I think healthcare in the United States is kind of fractally broken: it’s broken on the macro and the micro, you just zoom in and you keep finding new kinds of breakage. If you look at the user experience for normal use cases: general practitioner acquisition, appointment booking and service delivery, usability is pretty poor. A lot of offices aren’t open at night or on weekends, you have to call them during business hours to make an appointment, you have to book a whole appointment just to get a flu shot, and there’s a long wait once you get there. So in recent years we’ve seen some new startups that are usability hacks. ZocDoc, a website that lets you see doctors in your area who have open appointment slots this week, lets you filter out the ones who don’t take your insurance and book the appointment online. MinuteClinics and other quick clinics at drugstores and in big box stores are also walk-in, low-cost ways to get quick diagnoses or shots.

This convenience, however, does come at a cost to the user. Patients on ZocDoc are often just going to book with the next available doctor. People who use MinuteClinics are skipping a longer doctor visit, so these patients might not get long-term preventive care or form long-term relationships with their doctors (Harihareswara 2007).

In the library world, ResearchGate and act similarly to ZocDoc. They’re hacks that patrons use to self-serve, which is great except that they’re routing around the kind of deep and long-term research help your institutions could give them.

Encryption: Let’s talk about privacy tools. Pretty Good Privacy (PGP) is basically the standard, the common standard for email encryption. But it’s incredibly hard to wrap your head around. Encryption tech in general has terrible usability. It has terrible usability, terrible customer support, terrible localisation to different languages and locales, and thus, abysmal adoption rates. As a result, journalists and dissidents and activists generally don’t use it, even when the stakes are really high. They’re instead using Twitter and Facebook and email – unencrypted – because they are much easier to use. The Open Internet Tools Project’s James Vasile said at the keynote at Open Source Bridge 2013 that the privacy tech community would be better off spending the next year of our time, spending all of that time, on user experience design, localisation, and end user customer support, rather than writing any new tools or features (Vasile 2013).

Why the Bottleneck?

These examples – banking, lending, Wikipedia, healthcare, encryption – show you how bad usability can really change what choices people make.

We in the open source community, including Code4Lib, put a lot of energy into lowering visible barriers to entry, like licensing and cost, that stop people from getting information. But bad usability is a barrier to entry, too–less visible but just as real.

Free access to education, free expression of political opinions, and privacy from unwarranted surveillance are human rights in the UN Declaration of Human Rights [8]. Even if you don’t want to go that far, they are social justice goals that I think we can all agree on here. Our community shares a vision of less waste and more empowerment and getting knowledge into people’s hands. But transferring these benefits out of our libraries and into the hands of our users, the new Last Mile Problem, requires that the users actually be able to use our software. In getting rid of user experience obstacles, we are working to achieve social justice goals and implement human rights.

It’s so clear why we ought to make our products usable , but why do we have this bottleneck? Why do we have this barrier? It’s not just that the problem is hard. We’ve had other hard problems in the tech world – from going from mainframe to web, distributed computing, localisation — that we have done better on than usability: so why?

This isn’t just about coffee. Let’s look at what it takes to do user experience work. You have to look at your service from the point of view of someone who knows a lot less than you and see where they’re coming from. You have to imagine the reasons why they want what they want. Seeing that causation, seeing the connection between what someone’s doing now and all the causation that went before it, that’s empathy. It’s a little like reverse engineering. You’re trying to break the DRM (Digital Rights Management) that’s stopping them from getting what they need.

We need to exercise a disciplined empathy. It’s an empathy that includes qualitative thinking, like interviews and watching people use stuff to see where the snags are, and quantitative thinking, like A/B testing and heat maps. The tech industry is not very good at empathy. I’m speaking from my own experience here–I know library tech is its own field–but in my experience, we just drop the ball on empathy and hospitality a lot.

One reason is that our industry systematically undervalues the jobs and roles that require empathy and has deeply gendered associations with hospitality and empathy is that they’re not seen as masculine traits. This isn’t simply a women-versus-men issue; it affects everyone. The tech industry values masculinity over femininity, meaning traits like hospitality are devalued. Those who perform or reinforce masculinity — whether they’re male or female, are privileged. Everyone, women and men, become trapped in this cycle of usually unknowingly reinforcing hospitality, empathy, and so on as stuff that can lead to demotion on the respect ladder and the pay scale ladder. Naturally, all this stuff is then smushed out of our software, because it’s just not incentivized, it’s actually penalized, and when the group making the software isn’t very diverse, the cycle just repeats, and becomes even worse.

This is one reason that diversity in a group, especially a group making software, is useful. It includes people with different perspectives and is more likely to include more people with the ability to see issues from multiple perspectives–including the users’ perspectives. In general, marginalized people develop more empathy than the dominant group because we have to. We have to be able to see from other people’s points of view, including the dominant point of view, as a matter of survival, and we need to be able to see from many different users’ points of view, even when it’s uncomfortable or shows us that we have failed [2].

What You Can Do

A disciplined empathy means that we need to treat customer support, those front-line desk and phone tasks, as a first-class responsibility and a source of important data. These are your bug reports. This is how you know if you aren’t being as hospitable as you want to be. I’ve heard lore about a library where they log, in a shared document, every time they have to tell a patron “No,” and then they try to fix that.

Disciplined empathy means coders listening to designers, designers and coders learning to speak each other’s languages, and designers learning how to integrate their work into the development workflow. And this is happening. In her blog post, “Code Talks and Designers Don’t Speak the Language”, Crystal Beasley says that in general, coders right now in the open-source world don’t know what to expect from user experience designers, and developers don’t have good judgment procedures to know whether a proposed design is correct and that “representing the work of a designer requires a shift in culture,” with which I agree. Beasley also says, “The solutions to all these problems lie in communication and building a trusted relationship. It’s a higher barrier for designers that takes time to overcome. I’ve found all of my team to be receptive when I’ve taken the time to explain the principles that guide my decisions [10].” This is a good point. I think in any negotiation, it’s good to help people see the principles you’re reasoning from, and the experiences you’ve had, that led you to where you are now.

If you don’t think empathy is one of your strong suits, you can change that. We all came into this community with some skills and without others. You can learn and exercise your empathy skills as well. If you have a sequential learning style where you prefer a structured approach, you could take a course in conflict resolution. If you prefer self-study, you could read novels and blogs written by people with lives very much unlike yours. At your own institution, observe real users using your library and your library’s digital services, including patrons and colleagues.

Let’s Go

As Bess Sadler once said to me, “At this intersection of technology and librarianship, we need to not only bring technology skills and values to library services; we need to bring library skills and values to technology services.” And I’d say that includes hospitality and access.

Here are some of the resources that you can access right now.

  • University of Michigan’s Library Information Technology group has a User Experience Department [3], and Suzanne Chapman, Interface and User Testing Specialist and head of the University of Michigan Library’s User Experience Department, also has a really interesting blog [4].
  • University of Illinois’s Library has a usability testing lab with two workstations and a room set up to conduct usability studies [5].
  • Matthew Reidsma at Grand Valley State University Libraries has this awesome “Work Notes” blog so you can see, for instance, how the GVSU Web team responded to data and anecdotes to make incremental improvements to their site. I also suggest you read his pieces “The Library with a Thousand Databases” [6] and “How We Do Usability Testing” [7].
  • is a quick and easy-to-use site that lets you commission a test. Testers perform tasks and record and narrate on video what they did. It’s cheap; someone I know commissioned a test for $89 and got results in less than an hour. If you just want to start with usability testing and maybe just find some glitches in what you just rolled out, this is an option.
  • InFlux, a consultancy started by Aaron Schmidt, Amanda Etches, and Nate Hill, focuses on library user experience [8].
  • Within LITA, some folks have proposed a User Experience Interest Group [9], that’s also something to look into.

Libraries are doing this work. Sometimes we call it UI, sometimes we call it Human-Computer Interaction, sometimes we call it user-centered design or interaction design, and it intersects with product management. Several people on the Code4Lib email list in October talked about what a huge difference a dedicated UX team or person makes. For example, Tom Cramer said, “We have been lucky to have a full time interaction designer within our library IT group for about 6 years. It makes a world of difference in the quality of our products (Cramer 2013).”

Better user experience is the best force multiplier we have at our command, so it is vital that we make it a first-class priority, throughout the development process. And with disciplined empathy we can do that. Here at the intersection of libraries and tech, we can figure out how to scale hospitality, fix the new last mile problem, and actually achieve the social justice goals that so many of us got into this for.

Conclusion: Post-speech Reflections

After my keynote speech, attendees responded with approbation. One attendee tweeted, “The last time I heard the word “hospitality” used this often was at the Catholic Worker. #c4l14 #justsaying” [10]. Another said, “I want to take yesterday’s keynote, Bess’ last 2 years of talks, Matienzo’s lightning talk from 2013: burn to a dvd, send as a mass mail” [11]. An archivist used the talk as a jumping-off point to ask, “What kind of user experience are we providing to our researchers from start to finish?” [12]. Outside the immediate code4lib community, a specialist in infotech for international development also found my talk applicable to her work: “…if we want to use technology–any kind of technology, from radio to broadband–to give people more options and choices in their lives, we have to get imagining. We don’t really have a choice” [13].

As I look back a year later, I see related discussions (including Andromeda Yelton’s keynote from Code4Lib 2015) continuing in our communities, and I am particularly happy to see research and development continuing along the lines I described. For instance, Library Simplified [14], from NYPL Labs, is going to launch an e-book lending product for New Yorkers in the middle of 2015, and will be working to help other libraries use the software. Work on usable security by Adrienne Porter Felt [15] and others has improved the UX of privacy for millions of web users, and points to opinionated design principles that libraries can use to empower patrons while keeping them safe.

Perhaps the best response I received was during the Code4Lib conference last year, in Raleigh. I was looking for an acquaintance in the hotel lobby, and poked my head into the bar. I saw a stranger wearing the conference badge, so I greeted him, and he said that he’d liked my speech. I asked whether there was anything in particular he’d liked. He quietly told me that he’d been working in library technology a long time, and had just been through a long stretch of feeling ground down. But my speech had reminded him of why he’d gotten into this particular business in the first place – why he was here. That touched me. And I hope it continues to help him, and anyone else who needs it.


I want to thank all the people who helped me work out the ideas in my original speech: Coral Sheldon-Hess, Mel Chua, Andromeda Yelton, Bess Sadler, Emma Molls, Leonard Richardson, Jared Zimmerman, and Sky Croeser. And I want to thank all of you for the work you’re going to do, hacking yourselves and your institutions to serve users better.


[1] See Bess Sadler’s “Creating a Commons” ( and Mark Matienzo’s “Emotion, Archives, Interactive Fiction, and Linked Data” (
[2] For further reading see Mel Chua’s notes ( Kacey Beddoes’ “Engineering Education Discourses on Representation: Why Problematization Matters.”
[15] For further reading, see


Beasley, C. 2012, October 12. Code talks and designers don’t speak the language. Retrieved from

Cramer, T. 2013, October 30. Usability person? [Online forum comment]. Retrieved from

Harihareswara, S. 2007, January 16. Bad Relationship Retrieved from

Servon, L. 2013, September 11. The real reason the poor go without bank accounts. CityLab. Retrieved from

United Nations. The Universal declaration of human rights. Retrived from

Vasile, J. 2013, June 18. Keynote address presented at the 2013 Open Source Bridge Conference, Portland, OR. Retrived from

West, J. 2014, March 10. Your new coffee overlord [Online forum comment]. Retrieved from

Wikimedia contributors. 2012, May 16. Research:Section edit modification. Retrieved from

About the Author

Sumana Harihareswara is a programmer and open source community leader living in New York City.

Leave a Reply

ISSN 1940-5758