A cautionary tale about design and phone numbers

A cautionary tale about design and phone numbers

I want to write about a mistake. I want to explain where it came from and how my team and I prevented it from getting out into the real world.

Back story

I went to Kenya late last year to do design research for Ushahidi. During two weeks of field studies, we discovered that our partners, 20-ish local NGOs in Kenya, Tanzania, and Uganda who all work on HIV/AIDS prevention for adolescent girls and young women, need to send SMS surveys through the Ushahidi Platform to thousands of beneficiaries with no access to smartphones. We had a month to design, develop, and deliver the new feature.

To send SMS messages to a group of contacts, we needed a way to get those phone numbers into the system. We didn’t have time to build proper user management, CSV uploading, or anything else that looked like a normative contact management interface. This was also a feature-flagged, minimum testable product-style experiment, and it needed a quick way to get a whole bunch of phone numbers into Ushahidi. So I thought, text box. I knew from our site visits and interviews in Kenya last year that our partner orgs had these phone numbers in spreadsheet lists. I hoped they would be able to just copy and paste the phone numbers and be able to contact their beneficiaries. What could be simpler than copying and pasting into a text box?

I knew that an unstructured text field has a high risk for user error, but I figured that, with client-side validation and some helpful hint text, we could avoid the worst of it. Plus, I couldn’t think of another solution that fit our constraints at the time.

I thought I needed a simple input field, and I published a prototype that looks like this:

Obvious, right? Wrong.

This design made it through 10 user tests on 2 continents and at least 2 rounds of informal internal feedback from a team in 10 countries, before Carolyn, the dev programming the error handling on my innocent input field, called out a massive assumption that I missed. This is what it looked like on Slack:

Her simple question, “Are we ignoring them for now?” has real ethical implications. Here’s a hypothetical scenario to illustrate why: what happens when I assume everyone has 10-digit phone numbers? Everyone who doesn’t have 10-digit numbers can no longer use our tool. What if there’s a tsunami in Bangladesh, where I learned, thanks to Carolyn, people have 11-digit numbers, and they can’t reach out to anyone using our crisis response platform? My input field could silence the voice of someone in need to disastrous effect. This completely plausible, terrifying scenario makes designing Ushahidi fascinating and complex. It also means that we, by virtue of the people we aim to serve, don’t believe in edge cases.

The ethics of the edge case

Another wonderful colleague, Eriol Fox (Ehh-roll), sent me a talk by Mike Monteiro from a conference they went to in Copenhagen. Monteiro talks about edge cases, the outlying user profiles product teams willfully ignore, and how writing someone off as an edge case equates to ignoring their needs. He quotes Eric Meyer in his Design Ethics handbook,

“When you call something an edge case, you’re really just defining the limits of what you care about.”

Ushahidi explicitly serves the folks in other tech companies’ edge cases. In Monteiro’s words, “They are not edge cases. They are human beings and we owe them our best work.” I agree with Mike on this one. I bring this value into my everyday design practice, and yet my good intentions were still not enough to prevent the assumption that my input field would be fine.

Little mistakes like this compound one another. Alan Cooper talks about this in a recent keynote at Interaction18 where he outlines a design ethics framework he calls “Ancestry Thinking” as an antidote to well-meaning technology companies who find their software overwhelmed by malicious bad actors. He makes an augmented Titanic analogy to explain how many small assumptions create tiny holes in the hull of an enormous software ship. We won’t find a giant, obvious iceberg to blame when our work gets co-opted. Thousands of little, well-meaning design decisions can add up to an alienating, discriminating experience for end users. My input field could have become another leak in the hull of a well-intentioned software product. Thankfully it didn’t.

It took a mindful colleague with different experiences than my own to catch the problem in the end. Carolyn caught this because, “[she] built surveys for people in Bangladesh where they have 11-digit phone numbers.” This is the value of having diversity of people and experiences in the teams building software tools. When I, despite my best efforts to question my assumptions, recognize my biases, and check them, bake my straight white cis male privilege into a design decision, I can count on my colleagues and a culture of open critique as another check.

Phone number shibboleths

Hubris played a part in my assumption as well. I thought a phone number input field would be simple. After a little reflection and some cursory internet searches, it seems obvious that phone numbers, like people, are massively diverse. Data is never simple. Knowing someone’s phone number can tell you a lot about them, and phone numbers often function as shibboleths. I can think of two examples from my own life:

1. What a phone number means in Toronto

I used to live in Toronto where there is prestige in having a phone number that starts with 416. It means you’ve been in Toronto for a long time, that you have experience, that you belong. I lived in Toronto for years without a 416 number and part of me always felt a little envy when I met someone who had a “proper” Toronto number.

2. What a phone number means in Behchokǫ̀

I don’t live in Toronto anymore, but the phone number odyssey continues. I live in a small First Nations community called Behchokǫ̀, in the Canadian North. Folks have told me that pretty much everyone in town has the same 6 digits at the beginning of their phone number. Many people, when you ask them what there phone number is, will only give you 4 numbers. Having a phone number with 10 digits instantly shows I’m a “Southerner”. Again, a simple phone number can function as a symbol of belonging.

These idiosyncratic intersections of human identity and technological systems make it so that designing those systems never gets boring. Something as simple and seemingly universal as a text input field or a phone number belies the endless permutations of meaning and nuance we associate with our data. I made the initial mistake of underestimating that complexity, and I was lucky enough to have a thoughtful colleague call me out on that assumption. A culture of vigilance and open critique, diverse product teams, and mindful research with the people who might use your software creates an environment where we can create things that have a net positive impact on the world.