Checking Our Tech Privilege
By Ruth Miller
There’s a belief in transportation planning that making spaces more accessible for those that need it indirectly improves everyone’s experience. Sidewalk curb cuts are good for people in wheelchairs, as well as people with strollers and bad knees. When the people that build public spaces understand what it’s like to need these allowances, the final product is better for all.
The same is true for technology. Products designed by and for cis, white, men have induced plenty of eyerolls, cringes, and safety risks among non-cis, non-white, non-male users. Similarly, when the people that make technology themselves have reliable and fast internet connections, cutting edge tools, and inexhaustible resources, they can easily assume everyone else does, too.
Tell that to a monitor in the Ucayali region of eastern Peru. Those that access the global internet do so via shared long distance WiFi links. Imagine a whole town that shares a single 8 Mbps connection. The links are based on line of sight, meaning a storm or bird can disrupt access for the whole community. Depending on the subscription arrangement, the whole town might have a certain download limit per day or month. This might sound alien to a Google developer, but even out there people have and use Android devices. So when a 500 MB software update comes out, and each phone starts downloading it simultaneously, the whole community goes offline for weeks or even months.
But really, wouldn’t everyone like things to load a little more quickly?
Spend enough time holding your breathe at a 4 kbps download, and you’ll start seeing web design a little differently. These are a few of the ways Digital Democracy’s staff and volunteers check our high tech privilege.
- Decide carefully if more tech, and not less, is really the answer. Is a mobile form necessary, or would a paper one work just as well? “If you build it, they will come” applies to apps, too. Draft user requirements, build prototypes, and sincerely ask the right people about them before writing code.
- Push the limits of responsive design. Is video absolutely necessary, and if so, is there a way to display meaningful content for people that can’t see the video? Don’t expect a user to download a bigger image than necessary. This means both width/height, but also resolution.
- Don’t assume wifi or cellular access will be good or reliable. Tools like Sync and AirDrop allow people to wirelessly transfer files without an internet connection, and we’re building peer-to-peer offline syncing into many of our tools.
- Be aware of the power dynamics inherent to wealthy white people giving expensive equipment to non-wealthy non-white people. We’re sensitive to creating dynamics that reflect traditional colonial dependency, and truly want to empower these communities to not just use these tools, but use and maintain them without us. We’re not interested in collecting data ourselves — the data belongs to the communities, and they do with it what they determine to be best. If they don’t always do things the way we’d want, or if things go missing, that’s ultimately fine. These are our partners, and we all achieve better long term outcomes when we treat them like such. Take the incredible Laurenellen McCann’s “build WITH, nor FOR” and apply to at every level of project planning.
In the end, the Global North and the technology creators that reside here can’t let our love of faster, bigger/smaller induce us into forgetting that our experiences are far from universal. “High tech” isn’t always “better tech,” and more deeply understanding more diverse experiences will lead to more effective outcomes for all.
