Friction and UX design
I’ve been thinking lately about the concept of friction in UX design.
I made YANA (my notetaking app) for myself. I’ve always wanted something like it.
Usually when you’re designing something, you ask your target demographic what they want. My target demographic was, well, me. So I did a lot of introspection on what I expected from a software product.
I found that a lot of it revolved around very small optimizations. The core of YANA is the tagging system, but I could easily do something similar with Google Keep. The selection system couldn’t be replicated, but the tagging could, and with that a lot of the functionality I wanted with YANA could be achieved.
Even then, I found myself wanting YANA.
Why? Most of functionality I wanted could be achieved in Google Keep. Why spend a month making my own?
Obviously, I like making stuff. But UX friction is also part of the answer.
Saving Seconds
One of my favorite scenes from The Office is Kevin trying to save time by using smaller words.
He gives up pretty fast. Turns out, it’s not worth saving those seconds.
So why do UX designers try to do same thing? When I made my own custom notetaking app to save a few seconds on tagging posts, wasn’t I pulling a Kevin?
To understand the difference, we should look at the concept of friction.
UX Friction
In the grand scheme of things, optimizing a button to save 2 seconds each time the user amounts to…pretty much nothing.
Here’s the thing though — it’s not about the 2 seconds. A button that takes 2 seconds to press is a button users will not want to press.
If the users is going to press a button no matter what, then it taking 2 seconds each time doesn’t matter all that much. To borrow a term from economics, if the user’s demand for the button is inelastic, then sure, it’s no problem if it takes the user 2 seconds to navigate through menus to press that button.
But usually that demand is elastic. And if your button takes more than 2 seconds to find, the user just won’t press it.
That’s why I never used Google Keep’s tagging function. It requires one click more than YANA does. Note that the friction for me using YANA is intrinsically lower, because I made it. I’m not claiming it’s some genius UX — in fact, it’s probably (definitely) less polished than Google Keep!
But for me, shaving those few seconds mean I use the tagging system more. It’s not about saving those seconds; it’s about encouraging users to use a feature by decreasing friction.
UX today
A lot of trending issues in UX today can be reframed as friction problems.
What I described with Google Keep’s tagging system was an example of too much friction. But having too little friction can be a problem, too. It’s like mechanical engineering — you need the right amount of friction in the right places; too little or too much and your machine won’t work properly.
An example of insufficient friction? Infinite scrolling in social media apps. Lots of designers have framed infinite scrolling as an example of unethical UX design, because it leads to phone addiction. Of course, the jury’s out on that. I do think it’s fair to say infinite scrolling offers a sub-optimal amount of friction.
The concept of friction extends beyond the obvious realm of UX, too. A big part of the gun control debate boils down to how much bureaucratic oversight we want over gun ownership — in other terms, how much friction there ought to be between individuals and owning a firearm.
You can even use this concept while designing an API. There’s a method in React called dangerouslySetInnerHTML. It’s, well, dangerous, so the makers of React decided to force developers to type that word out every time they wanted to use it — thus increasing friction.
To quote them, “Our design philosophy is that it should be “easy” to make things safe, and developers should explicitly state their intent when performing “unsafe” operations.”
That exact method, dangerouslySetInnerHTML, is used in YANA. Thanks to those warnings, I was reminded to take plenty of precautions in my code.
Another example of this in the React API is appending UNSAFE before deprecated lifecycle methods, like componentWillMount().
One last example, that stupid Superhuman email client that costs 30 bucks a month or something. I don’t know much about it, but I hear it makes the little things super smooth. From what I can tell, they’re making a fortune off of it, so they must be doing something right.
Conclusion
In some respects, designing a product is like designing a car. You want to think about which parts you want to be frictionless (bearings) and other things to have as much friction as possible (wheels). Many problems in UX can be designed to fine tuning how much friction there should be for certain features.
P.S. I said the Superhuman example would be the last example. But here’s another very funny (or sad?) example of friction design: shock bracelets.
