More and more, I feel like we’re fighting a bizarre wave of apathy in tech. Not apathy towards new technologies, of course – there always seems to be plenty of energy for developers to spend on debating Vue vs. React vs. Angular, web 2 vs. web3, etc. The flavor of the week as I’m writing this happens to be AI chat and art generators, but the actual technology doesn’t really matter, here. This isn't a callout of a specific app or technology - it's a mindset that feels frustratingly pervasive in the industry as a whole. I’m talking about a broader apathy towards the human beings who we – at least hypothetically – want to be users of the things we’re building with these technologies. Somehow, they never seem to factor into the equation.
Maybe you’re familiar with “the happy path”, the phrase we use in software and UX to describe the ideal user flow. The happy path is what happens when the user does everything just the way we (the developers) predicted: it’s how our apps would work if they were used by Stepford Wives who live in a world without typos, slow internet connections, last names that include special characters, or human error. We spend a lot of time thinking about, designing, and developing the happy path because the happy path is easy to build, easy to sell, and fast to ship. It’s also heavily biased, because it reflects only our own experiences and assumptions – not the diverse and varied lived experiences of the users that we are (again, hypothetically) doing all of this for. The happy path, of course, isn’t real because our users are humans, not robots (or clones of the developer). What developers neglect, regularly, is the unhappy path.
When we do think about the unhappy path, we prefer to focus on the milder side; the kinds of low-stakes, low-risk “oopsies” that we often catch in QA testing. You know: “A QA tester walks into a bar. They order a beer. They order 2 beers. They order two beers. They order 7348594350 beers. They order -1 beers. They order a deer.” The joke continues, but I’ll spare you. Suffice it to say, we slap a few error messages in there to handle validation errors or mis-clicks, forcefully redirect the user back onto the yellow brick road, and call it a day: unhappy path, handled.
But that’s not really true, is it? Because when we’re doing that, just paying lip service to the unhappy path, we’re glossing over the very real potential for active abuse and harm caused by our own creations. It sounds extreme when written that way, but that's because it is. And it happens all the time in our industry, with no real excuse beyond just...caring more about the thing we're coding than the people who will use it. I'm talking about social networks launched without blocking or safety features, camera filters developed without testing on darker skinned people, prediction models trained on biased data, AI image generators that spit out portraits with exclusively European features, whole swaths of the web made completely inaccessible if you’re blind, Deaf or hard of hearing, or have a cognitive condition. At the risk of sounding cliché: “Your [developers] were so preoccupied with whether or not they could, they didn't stop to think if they should.”
Most often, I see this complacency and laziness disguised under a nicer name: “MVP”. Calling something the MVP imbues it with some kind of magical sense that we don’t have to do it all right now; we’ll just make the app accessible, inclusive, and safe…later. Because those things, of course, aren't part of the minimum requirements of software development. But the users we subject to those inaccessible, noninclusive, dangerous MVPs are real people, with thoughts, feelings, and experiences that I’m whole-body tired of watching developers disregard in their quest to be the first one to ship The Next Big Thing. When you “move fast and break things”, what you’re breaking are other human beings.
I also see a lot of developers who are quick to dismiss this because they don’t think they’re building anything big or important. “Hey, I’m not a FAANG dev. I don’t work in healthcare or anything. What impact will my little app or feature have?” Well, first off, the answer is "More than you think". You probably would have dismissed working on a social media year-end greeting or coding a basic form as having minimal impact, but take a look at those links and see how small things can still do big damage.
But even still, developers are prone to thinking in percentages – reducing real human lives to statistics. When we say "I'm not working on a big app, so it's fine", what we're really saying is: “It’s okay since my app will only hurt some people. I’ve looked at the numbers and decided that is an acceptable amount of harm for me to inflict.” It’s the developer’s trolley problem, only there’s an option where nobody gets run over and it just takes a few more weeks to launch. I’m continually shocked how many developers look at that situation and pull the lever for the faster release date.
Users are more than a number – they’re not logins per day, page views per month, or engagement metrics to measure against our OKRs. They’re not even the persona that we’ve created in the hopes of lumping them into some easily digestible demographic: Kelly, the middle-aged secretary and single mother who uses our application to meal plan for her busy family (or whatever’s been slapped on the page, next to the first stock photo result for “40 year old woman”). Users are real people, dammit.
And personally, I’m so tired of trying to convince folks in tech to care about dark patterns, or safety features, or hiring diverse teams, or running usability tests, or any one of the numerous things you can do to at least attempt to minimize the harm you’re creating. It feels awful to always be the raincloud, the one who's solely responsible for pointing out where things could go wrong, because others just don't seem to care. I’m sick to my core of writing accessibility talks that spend the first 10 minutes justifying the investment of time in terms of ROI – you should build accessible apps because the people using your app matter. I shouldn't have to make a business case for treating people with respect. If you don't already understand why that's important, I cannot explain it to you in a 20 minute conference talk. I don’t know how to explain to you that being a developer means you have to care about other people. If you can’t care about your users, then maybe this isn’t the job for you.
And yeah, we’ll fuck it up sometimes, because developers are human, too. It’s inevitable. But does that really mean we shouldn’t even try?
If we don’t start and finish every single project thinking about how the human on the other end will be impacted…why are we even doing this? Who the hell are we building for? It’s fine to build things for ourselves, for fun – that’s why we have code challenges, tutorials, hackathons, or side projects. But when we’re coding real things for real people, those users need to be centered throughout the entire process. When I see developers, teams, or whole companies who lose sight of this, it absolutely blows me away.
Software exists for humans, humans don’t exist for software.
*Title inspired by the fantastic article I Don't Know How To Explain To You That You Should Care About Other People
Top comments (0)