From Empathy to Advocacy

For the past several years, I’ve been privileged to work with a number of local advocacy organizations in my community. Doing so has made me keenly aware of the crucial role that advocates play. They operate on scales both large and small—from working with lawmakers to shape public policy, to helping a single parent fill out the paperwork to find child care that enables them to keep a job. But advocates have a few things in common:

• They have a cause: in whatever context they work, there’s an existing pattern they’re not satisfied with.
• They intervene when they perceive an imbalance of power.
• They act as translators between “outsiders” and “insiders.”
• They persuade others to care about their cause, using stories and hard data.

As people who make websites, we may find that thinking of ourselves as advocates for our users, rather than creators of a product or providers of a service, transforms the way we work.

The UX industry devotes considerable attention to the concept of empathy, and rightly so, as understanding our users and their needs is foundational to delivering quality experiences. Still, empathy and insights alone do not automatically create those experiences. What matters is how cultivating empathy alters our decisions and behaviors. My ability to understand the needs of another person does nothing to meet those needs until I take conscious action—becoming not just a listener, but an advocate.

Most of us probably feel that we practice user-centered design, but the work of web development doesn’t happen in a vacuum. It frequently means inheriting a legacy of past decisions and considering a multitude of business pressures. It’s messy, and users often suffer as a result. Advocacy is what we do to make it better. It’s how we navigate the complex world of business relationships and persuade others to care about the same principles we do. And by making the language of advocacy a part of our daily conversation, we’re constantly seeking to build a culture of respect for users, rather than waiting for a project that provides a convenient framework.

Imbalances of power#section2

Advocacy can take many forms, but one way to think of it is that when any significant power imbalance exists between two parties, the risk of an injustice occurring is high. The greater the difference, the greater the risk.

A person can feel powerless for many reasons. Being a child is an obvious example, as are differences in social or economic status. I can be privileged in one context and powerless in another. We all feel powerless whenever someone else makes decisions for us. When I go to the doctor, I’m signing up for whatever procedures are ordered, often without knowing what the cost will be. When I file my taxes, the government decides whether I’ve gotten them right.

In the face of a large, complex system, someone who feels powerless needs an advocate, usually one who works within the system, to gain a hearing. Otherwise, it’s too easy for the privileged party to make every decision based on its own interests and preferences, even if unintentionally.

That’s why governments and large organizations sometimes employ ombudsmen, who operate outside the normal chain of command and elevate complaints that might otherwise go ignored. Other advocates wear the hat informally, simply as people who care.

In developing web applications, I might be tempted to think that ultimate power always lies in the user’s hands. After all, I assume, she controls the browser and can always take her business elsewhere. But in many cases, this is more of an abstract idea than a true lever of influence.

Will she really leave the social network that all her friends use? And if she did, would I, as a developer, ever know the reason? There are many applications that people are forced to use without a good alternative, like those provided by an employer. In many cases, the business offering a website holds much of the power in its interactions with users.

Even when choices do exist, users are still not the ones making design decisions—they can only react to decisions already made by developers and others, and hope that someone is listening. Voting for change by leaving a website is unlikely to mean much because it’s a passive statement.

Experiences can also be hard to quantify. For example, when language barriers are creating a UX problem, it’s hard to measure the resulting frustration or its cost in goodwill.

In a culture of advocacy, the conversation starts from an underlying value of respect for the user, rather than the balance sheet or even an abstract idea like “best practices.” We can’t always say that adding translation, or making our writing more accessible, will improve our customer satisfaction metric by a given percentage. But we can say, “We ought to be an organization that recognizes the diversity of our customers and respects their time. Let’s demonstrate that by…”

The most effective advocate is likely one who has direct experience in the user’s shoes. The bilingual team member is most likely to be sensitive to language barriers. This isn’t always the case—anyone can champion a cause—but it does mean that as developers, we need to pay extra attention to the people within our organizations who have such experience. We can encourage them to act as advocates in those areas, and to remind us of priorities that we might otherwise overlook.

We must put structures in place to give such advocates the power to be heard, though. Ombudsmen hold positional authority that, while not absolute, isn’t easily overruled. In the design or development process, that structure may be formalized as a specific role within the development team (“Eve is our user advocate on this project”), or an expression of shared values that says, “If anyone feels that a decision doesn’t demonstrate respect for our users, we stop what we’re doing and tackle the issue.”

Translating between insiders and outsiders#section3

An advocate also serves as a translator, helping outsiders to navigate a complex system and helping insiders to understand an outsider’s position. Doing this effectively can be challenging and involves a mix of both technical and soft skills.

In web development, interviews and testing will, of course, yield insights into users’ needs. But users can’t be expected to articulate those needs in a way that makes sense to developers. A good advocate will listen, draw inferences, and re-interpret needs in ways that lead to practical application at a technical level, so they can negotiate effectively with developers or other business stakeholders.

An advocate’s analytical skills, and a level of impartiality, can be just as crucial. Users may ask for the moon. They may describe symptoms instead of the fundamental problem, or jump to conclusions about what the problem is. For example, when a user complains that “the system is slow,” it might mean that response time is poor, or that the system is confusing and accomplishing a task takes too long. The user might feel strongly that the solution is adding a search system, when in reality, a few IA improvements would be effective.

An advocate’s role is to distill core problems from the raw input of feelings, reactions, and data, and, just as a lawyer might, recognize the moments when a user asks for what is not in their best interest. What people like is not always what’s most effective (although this is not an excuse to simply replace their subjective preferences with our own).

Collective interests and individual stories#section4

“Users” are a faceless and voiceless mass. Alice and Bob, on the other hand, are people. An advocate’s third task is to make the impersonal personal by articulating the interests of a group and helping decision-makers to see them as people rather than numbers.

One of the most persuasive presentations I’ve ever attended came from a Boys & Girls Club spokesperson describing their work. It was persuasive because she did a masterful job of combining big-picture data about the effectiveness of certain programs with specific stories of children she’d worked with. It’s one thing to advocate for early childhood programs based on economic data; it’s quite another to show how a particular child’s life was changed through a development program. Collective data represented through individual stories become compelling.

It’s easy enough to write off the experience of a group of people when we describe them with a label—“IE7 users,” for example. It’s even easier when the label describes a minority of our audience. But if I think about my friend Alice, who works in a healthcare setting where computers are difficult to upgrade because of regulatory concerns, it’s much harder to explain why she deserves to be marginalized.

Stories are persuasive because they humanize the subject matter and help us connect emotionally. That’s what makes personas a valuable tool. But when we encounter resistance, they’re also easy to dismiss as anecdotal unless they’re supported by harder data. If I want to make the point that we shouldn’t ignore the experience of IE7 users, I need to know how many of those users I have. The developer who really doesn’t want to deal with IE7 might say that they’re “less than 5% of the audience”—a purely quantitative argument that sounds reasonable. But perhaps that 5% represents thousands of individual people. When I tell Alice’s story, explaining that she’s powerless to change the browser her employer provides, and point out that we have thousands more customers just like her, the argument carries more weight.

Advocacy in practice#section5

Design decisions always require that we balance competing interests, but as a user advocate, I believe that it’s the user’s interest that should generally carry the most weight. Likely, not everyone in a business will agree, at least not all the time. To build credibility in speaking on behalf of users, consider the following practical guidelines.

Affirm the legitimacy of other interests#section6

Rarely is a business openly hostile to users, of course. But we all bring to the discussion a set of preferences and biases that stem from our experience and expertise. Executives have an interest in the financial performance of the organization. Security professionals have an interest in protecting systems from intrusion. Developers want maintainable code and database integrity. Marketers want a strong brand image.

These are perfectly valid goals, but each of them can easily find itself in tension with what the users of a web application care about. Users probably value things like a good price, a clear interface, and software that lets them complete a task quickly.

An advocate exercises empathy not only on behalf of the user, but also on behalf of the business. To be heard, I need to first understand and respect what decision-makers value. Over the years, I’ve had many discussions with security professionals about the inherent tradeoffs in balancing usability with security—the most secure system is always the least usable. The UX person’s “clear feedback” in a failed login interaction is the security person’s “information leakage,” for example. To strike that balance well, I have to respect the need for security and the very real threats that face modern web applications. If ease of use were my only priority, I could easily put an application at risk.

Frame the discussion in meaningful terms#section7

Respecting the goals of business stakeholders enables us to make a case for user-first decisions in ways that command attention. UX considerations can often be framed as risk management, brand management, or other business values.

For example, imagine that a website is offering a survey to users to get background research for a potential new product. The data will drive critical decisions, so everyone believes it’s a user-first project. But the survey takes over the user’s screen about 10 seconds after page load, so it’s frustrating. The conversation could easily go like this:

UX person: We’ve got to do something about this survey. It’s driving people crazy.
Research person: We really need the data. And people want to have a voice in our design process, right?
UX person: We could make it less intrusive, though. It doesn’t have to take over the whole screen.
Research person: Then they won’t notice it, and we won’t get enough data. We have to make it obvious.
UX person: Our users are annoyed.
Research person: It’s worth it for a little while. They’ll benefit in the long run.

A more effective approach might be:

UX person: Can I talk to you about the new survey? I’m really glad that kind of research is going into the new product.
Research person: Yeah, it’s exciting.
UX person: We’re hearing some complaints about the timing, and the way it takes over people’s screens. Could we adjust that? I’m afraid that frustration could really bias your data.
Research person: Oh, I hadn’t thought about that. We really need it to be obvious, though. If we don’t get enough people clicking through, the whole thing will be useless.
UX person: Definitely. Can I show you a couple of design ideas?

To someone who lives and breathes UX, user frustration might be a sufficient reason to make a design change on its own. But to the analyst who needs that survey data, it might seem like an acceptable tradeoff. Articulating the risk that frustration poses to the business, like biasing the results of a survey, can make the argument far more persuasive. And proposing a workable alternative is always more effective than simply highlighting a problem.

Be pragmatic#section8

If we recognize that other business interests have merit, we have to be prepared to lose UX arguments at times. A business is not a person, and the cold logic of operational calculus may determine that the cost of making a change to improve UX outweighs the benefit. Advocates learn to choose their battles and press for change where it matters the most.

In the case of language barriers, as much as I may like to see full translation of a website or application, it’s likely an expensive proposition many businesses won’t be prepared to accept. But perhaps there are a few key interactions where it could be especially helpful, and we can advocate for a limited expense there. And if that doesn’t fly, we can fall back to simplifying the writing as much as possible to make it accessible to non-native speakers. At each step, even though the solution isn’t ideal, it keeps the issue visible, and keeps people thinking about the needs of that group of users.

While a business may be an impersonal entity, it is also composed of people who, for better or worse, share a common culture. As web professionals who continually speak in the language of advocacy, we can cultivate an environment in which users are respected, even when we lose out on individual decisions.

Find a cause and start somewhere#section9

The advocates that I’ve worked with recognize their limits. They are passionate about a cause, but they know they can’t change the world all at once. They tackle manageable problems while always watching for new opportunities. Start by finding the single UX issue that you care most about, and look for small ways to improve it and persuade others to care. It could be one of the big issues of our day, like front-end performance or the mobile experience, or something very specific, like the experience of a handful of internal users with a particular administrative interface (which are easy to neglect—and improving them is a terrific way to get buy-in for future efforts).

At the same time, just as solving major social problems depends on public policy, our industry can only improve when we advocate publicly—so it’s important to write, speak, and share our experiences, particularly those that may be unique or underrepresented.

But whether the scale is large or small, the key is to encourage, in ourselves and in others, a healthy level of dissatisfaction with the status quo and take daily actions that directly improve the experience of our users.