Friction as a feature
Emil Kowalski’s short essay Friction as a Feature begins with the consensus: “We treat friction as something bad. It makes us slow, inefficient, messy. Products brag about removing friction.” Whole companies exist to be frictionless. His argument is that friction was quietly doing a second job the whole time: “it made us think before we built.” Before AI, writing code was expensive, so the cost of building set a threshold on which ideas survived long enough to exist, and you had to be selective because the effort forced the decision. AI removed that cost, an idea can become an app in minutes, and the bar for what is worth building dropped with it.
He is fair to the other side. Cheap building is itself a way of thinking: building option A and option B and comparing them often validates better than theorising, and “Prototyping is thinking.” But only if you actually validate, and with no friction nothing stops you from shipping both. That, he says, is why people dislike the flood of vibe-coded apps and UI libraries. There is rarely a thought behind them because there was no friction to force one. “They don’t feel designed, they just exist.” Remove friction entirely and the only thing left is output, which feels meaningless and without texture. His conclusion is the title: friction forces judgement and filters out the ideas that do not deserve to be built. “It’s a feature, not a bug.” He credits the framing to tweets by Swami and Drazen.
The essay is about making things, but the same idea runs through the interfaces he builds, and it is worth following it there because it is the one place in this chapter where motion is used to slow someone down on purpose. In Building a Toast Component he describes dragging a Sonner toast the wrong way. Instead of simply refusing to let the toast move upward, “you can still drag it, but it will slow down and eventually stop. It’s nicer than just stopping the toast immediately.” Vaul does the same at the top of a drawer: drag upward when you are already at the top and the drawer damps the drag, so the more you pull the less it moves, because “things in real life don’t suddenly stop, they slow down first.” His skill file names the pattern in two lines, friction instead of hard stops and damping at boundaries, and Rauno Freiberg’s Control Centre example from the last section is the same physics on iOS.
Friction can also be the whole interaction. The skill file’s hold-to-delete pattern, which is also an exercise in his course, makes a deletion cost two seconds of sustained pressure: the fill transitions to inset(0 0 0 0) over 2s with linear timing, and if you let go early it snaps back in 200ms with ease-out. The slow, constant fill is the friction. It gives the person time to notice what they are doing and a cheap way out. That is the interface version of the essay’s argument: a little resistance in front of an action makes you decide whether you mean it.
The counterpoint is that most of the time you are removing friction, and Emil is the first to say so. The reason Raycast gets no animation in 2.1 is that he opens it with a goal in mind and wants to do his work “with no unnecessary friction.” Sonner’s swipe is momentum-based so you do not have to drag past a threshold; a fast flick dismisses even a short drag. Vaul lets you flick a drawer shut and even skip snap points. Subsequent tooltips open instantly. The skill file’s asymmetric timing rule is the same judgement in one sentence: slow where the user is deciding, fast where the system is responding. Friction belongs in front of decisions, never in front of work.
That is also the shape of the whole chapter. Animate less. Ask what the motion is for and how often the same person will see it, and if the answer is decoration at high frequency, delete it; Rauno and Emil both arrived there by feel and then by reasoning. When something does earn motion, mean it: an ease-out that lands gently, a duration that respects distance, a spring that survives interruption, a clip that reveals without shifting layout, a sequence that tells the user which layer they are touching, and a little friction exactly where a decision lives. Emil’s line from the toast post is the standard to hold yourself to: the less users notice, the better, because it means the thing is intuitive and they can get on with the task.