What product inclusion and Latinx Immigrants can teach WhatsApp
How a product inclusion framework can improve WhatsApp for all users
I can’t stop thinking about this story from a few weeks ago by Documented NY (a tech nonprofit!) about how Latinx immigrants are scammed on WhatsApp. It makes for a good case study in how we might apply product inclusion principles. Oftentimes, talking to your most vulnerable users can reveal larger, systemic issues. The case study is timely, as WhatsApp users are fleeing the platform for more secure alternatives like Signal — which is being driven, ironically, by misinformation across WhatsApp 🥴.
What is “Product Inclusion?”
Product inclusion is an emerging philosophy in software development that’s focused on how to build products that work for everyone, regardless of race/ethnicity, age, gender, ability, etc. Product Inclusion work can include projects around improving accessibility, expanding access to new or underserved populations, identifying and preventing bias, and more. Ultimately, I think it boils down to one question: Are all of your product’s users experiencing the same outcomes? Clearly, that is not the case for WhatsApp’s Latinx users.
As a starting point, let’s take a look at Google’s ABCs for product inclusion. Consider how these apply to the WhatsApp example:
Address the diverse needs of current and future users
Build for everyone, with everyone
Constantly test and improve for inclusion
Part 1. Define and refine the problem
Before going any further, let’s get clear on the problem and gather some data. We’ve heard that journalists have discovered that Latinx immigrants are being scammed on WhatsApp. But we need to go deeper before jumping to solutions. Here are a few directions:
Define the targeted user: What kind of data do we have on the relevant user segments — specifically on Latinx immigrants in the U.S., Spanish speakers, and Latinx users more generally?
Pull quantitative data and compare to benchmarks: How does the experience of our vulnerable population compare to that of average user or to white users?
Talk to those users and gather qualitative data: Find Latinx immigrants and talk to them. See how they use the product, ask for positive and negative experiences, discuss specific experiences with spam and misinformation. Find out the real impact that spam has on their lives.
Synthesize the quant and qual: What have we learned from this exercise? Perhaps you’ve identified that the problem is associated with all Spanish users, and not just immigrants.
Consider assumptions and blindspots, like the data you don’t track: Think about any missing data points or additional instrumentation you might need. You might discover that while WhatsApp tracks spam events, they don’t track fraud events. You might also realize that you don’t have any dashboards tracking the Latinx UX more generally. You can’t serve what you can’t see.
Put outcomes in context. Lastly, revisit your analysis with outcomes in mind. It might be the case that Latinx immigrants see spam as often as average users, but that Latinx immigrants click on that spam more often, and, further, are defrauded at higher rates. And the result is that those users are losing money, which is disproportionately damaging because they have less money to begin with. Remember that the same outcome can vary in impact by population.
Part 2: Design solutions
For argument’s sake, let’s distill the user problem to this: Latinx immigrants are more often defrauded on WhatsApp because they are less digitally literate, and in part because WhatsApp’s spam tools don’t work well in Spanish. I like this problem statement because it is specific, outcome-oriented, and it identifies two problem spaces (user education & content moderation). Here are a few takeaways for implementation:
[Process] Establish Spanish speakers as a key segment for research and QA. Before rolling out any new products of features, make sure you test them with Spanish speakers.
[Process] Be explicit about product inclusion during product reviews. Create an inclusion checklist, and ensure that anything you build meets certain criteria during reviews and before moving to testing or production.
[Measure] Set up new instrumentation and a/b tests. to measure and compare the Latinx experience to that of average users, white users, and other key segments.
[Measure] Monitor new dashboard and accept that conditions change (see: COVID). Track changes in new KPIs, like fraud events, and set thresholds for when you need to intervene. Vulnerable populations can become more vulnerable over time, as we’ve seen with COVID.
[Research and build] Explore the user problem around digital literacy. Do more qualitative and quantitative exploration of digital literacy. Prototype some education features (e.g., a special modal when sharing external links) and validate them with target users.
[Research and build] Explore the user problem around spam filters. Understand why your spam filters don’t work as well in Spanish. Perhaps your algorithms need to be trained on more Spanish content.
This isn’t meant to be a comprehensive approach — and I could probably write a post for every bullet point above. My hope is that these examples can help you understand how to apply product inclusion principles. This case study shows how improving the experience for one segment of marginalized users (Latinx immigrants) can in fact improve privacy/safety/UX for Spanish speakers and the broader user base.
I’ll have much more to say on this topic after I get my hands on Building for Everyone, written by Anne Jean-Baptiste, who heads product inclusion at Google. Excited to dig into that. XML