Friction for (Augmented) Humans
We want to add more friction to our software – to take out the ease of use that can spiral into addictive or abusive behavior. Even with all good intentions in the world, this friction can miss the mark.
Take a commenting system for this blog. An email based system, kind of like a Letter to the Editor, seemed suitable. One of its virtues was the friction it added. Someone had to open up her email, write a thoughtful response, and then click send. These steps would hopefully slow people down.
But if you look at my inbox here, it is nothing but spam. What I thought would add enough friction to prevent spam did not stop it at all. The stuff kept coming and coming. Why?
It was then I realized that I was thinking about friction the wrong way. For a person like you or me, the process of opening our email and writing an email and sending an email is enough friction.
But what about for a web scraper? Easy as can be. Once a bot has my email, it can send me all kinds of spam. The tables turn. Email is susceptible to all kinds of automated attacks. An industry for email security exists for a reason.
Friction makes sense when we are talking about a human. It disappears in light of humans augmented by automated processes. People design programs to go around systems that have built in resistance. Is that not the double-edged sword of programming? Sure, it makes things easier for us normal citizens, but it also allows bad actors to do things much easier as well.
When designing a system for friction, we also have to keep in mind how a person could run through our system with a program. How easy are the processes to automate? And what does that mean if the process is automated? Thankfully for my commenting system, the spam does not harm anyone. Nobody sees the posts and if they do, it is an amusing word soup. In any other context, however, it could prove harmful.
But not all of it is negative. People can write programs to automate your system to do normal tasks. That is what makes web API's so wonderful. And besides, friction can be added to API's via authentication and request limits.
So even though we are designing friction for people, we must extend the definition of “people”. Because it is not only people clicking through the instructions you laid out for them. It it also people who can program, who understand the processes laid out and can reverse engineer them, who know how to remove friction to get what they want. Not all of that is bad. We just have to keep it in mind.