Policy Harm

Much of the my personal frustration with the current state of web ideas are the lack of awareness around policy harms. The companion to policy harm is administrative burden. I’ve written a lot about friction and it’s part of these ideas, too. Namely, if you can frustrate someone enough, it’s easy to get them to do what you want them to do.

In the case of public policy wants, burdening people or forcing them to have “skin in the game,” gives a bureaucract the feeling they’re weeding out grifters. It’s the freeloader problem applied to public policy. In the context of non-public policy related issues, policy harm is still present and neglected, especially in the era of “move fast and break things.”

What is the cost of policy harm

The thing we have to reckon with as designers is what are the implications of policy harm and who pays the cost? Usually users are the ones who have to deal with the problems associated with unintentional friction built into user experiences, but bounce rates or complaints via reddit searches aren’t a good way to quanitfy the cost of these issues.

A few years ago, I worked on an onboarding experience for a single-sign on (SSO) where the exit rates in the flow were initially around 25% of the people attempting to sign up would quit before completing the sign-on flow. In this case, because user rates were in the millions, we considered that collateral damage a worthwhile cost, but in time, I came to understand that the team fixed the issues and that those rates dropped a lot.

Shifting away from things like software applications to real world experiences augmented by bad UX, think about traveling to a new city and dealing with their mass transit system. If you’ve taken the train in some far-flung city, you have to adapt to a lot of information from the outset and it’s often difficult if you haven’t visited before – or don’t have a host – to figure out where you’re supposed to go and what you’re supposed to do.

I was once in Atlanta and it was after hours and traveling to my hotel. For whatever reason, I threw away the single-use ticket I had because I didn’t realize they had exit fare where you needed to swipe before you leave the system. In order to get out of the MARTA station, I needed to push a button and someone shouted at me that I needed to keep the ticket and then reopened the gate so I could pass. This wasn’t a huge issue, but it was a bit jarring and represented poor service design.

I’m sure that at a different era, we’d have had someone working in the ticket booth and they could’ve dealt with this indvidually, but now we don’t hire people to do those kinds of jobs anymore with automation and even when someone is in the ticket booth, they don’t sell you tickets and they’re usually quite gruff and often unhelpful unless you’re lucky enough to find a kind soul who likes their job.

I think I will eventually connect this story to a broader conversation about trust experience and how to quantify the erosion of trust and what the role of service design in these design experiences can be.

Built with Jekyll, Github, VSCode and served via Netlify.