It's also completely correct, and in well over 15 years of using GitHub I have never once heard anybody complain about it.
We Got Really Good At Removing Steps
The industry learned a real lesson about friction in the late 2000s, and it learned it from checkout forms.
In 2009 Jared Spool's team pulled a single Register button out of a retailer's checkout and replaced it with Continue. Sales went up 45% in the first month. That's the case study everyone still cites, and it wasn't an outlier.
Every field you dropped from a signup flow measurably lifted conversion. Amazon had patented one-click checkout a decade before that and A/B tested the shit out of everything around it. The data was overwhelming.
Then it hardened into a rule. Fewer steps, fewer fields, and if a user has to stop and think about anything at all, then you failed.
Tax Versus Protection
Friction between a person and the thing they want is a tax. That covers the nine-field signup form and the interstitial nobody asked for, and all of it is worth removing.
Friction between a person and the thing they'd regret is protection. That covers typing the repo name, or the pause before a wire transfer clears.
Same mechanism, opposite job.
The industry flattened both into "steps" and then optimized steps toward zero, which is how you end up with products that let someone destroy three years of work with a stray click.
Where Friction Earns Its Place
Four places where I'd make something harder on purpose.
- Destructive actions that can't be undone. The GitHub pattern is the obvious one, though the better version is Gmail's undo-send window. It adds no friction at all in the moment and still protects you, because the safety net sits after the action instead of before it. When you can build the undo, build the undo. When you can't, make them type the name.
- Anywhere someone is learning something. This one has real research behind it. Robert Bjork coined desirable difficulties in 1994 for conditions that slow you down while you're learning and improve what you keep afterward. Spacing and retrieval practice both feel worse while working better.
One finding inside that work has stuck with me for a long time. Students in active learning environments learned more but felt like they learned less, because effort got misread as failure while a smooth lecture felt productive and wasn't. If your product teaches anybody anything, removing all the effort removes the learning with it.
- Making somebody care about the result. When instant cake mixes launched in the 1950s, people resisted them. The mixes made baking too easy, and easy made the labor invisible. Adding an egg back to the recipe fixed it. That's the IKEA effect, documented by Norton, Mochon and Ariely in 2012. People value what they built over what they were handed. Novices included.
There's a limit on that one. Labor only creates value when the labor works. Participants who built something and then took it apart lost the effect entirely. Friction that ends in failure annoys people and buys you nothing.
- Filtering. An application that takes twenty minutes keeps out people who wouldn't have stuck around anyway. Sometimes fewer users is the goal and the effort is the filter.
Why Most Confirmations Do Nothing
Most of them do nothing at all, and there's an easy way to spot which ones don't.
"Are you sure?" fails because people learn to click through it.
After the 40th dialog it stops being a decision point and becomes a reflex. You aren't confirming anything, you're adding a step to a motion someone performs without looking.
Typing the repository name works because it can't be done reflexively. You have to know what you're destroying and produce the name from memory or by looking at it.
The friction buys attention.
Bjork's research has the same nuance, and it's the part most people skip when they cite him. The difficulty has to be tied to the actual work. Difficulty that comes from confusion or bad instructions produces nothing and makes things worse.
Hard on its own does nothing. The hardness has to be doing something.
Same test applies to product design. Does this step force the user to engage with what they're about to do, or does it cost them two seconds and nothing else?
Prefer Undo To Confirm
Undo beats confirmation almost every time. I love an undo button. Can you imagine Photoshop or MS Word without an undo button? Why should your app not have one?
A confirmation dialog interrupts everybody to protect the small fraction who were about to make a mistake. An undo window interrupts nobody and protects the same people. The cost falls on the system instead of on the user, which is where it belongs.
Gmail's send delay is the cleanest example. It costs you nothing, you forget it exists, and then one day it saves you from replying-all to four hundred people with something unkind about one of them.
The catch is that undo is slightly harder to build.
You need to hold the action in a pending state, or keep enough history to reverse the operation, where a confirmation is a dialog and an if statement. That gap in effort is most of why the industry defaults to confirmation, and it's a bad reason.
So the order I'd work through goes roughly like this.
- Build undo if you can. Pending states and soft deletes cost engineering time and cost the user nothing, which is the right way round.
- If undo is impossible, scale the friction to the damage. A permanent delete of one row gets a confirmation. A permanent delete of somebody's entire account gets the type-the-name treatment.
- Reversible and low stakes? Add nothing. Get out of the way and let people work.
Most of what ships lands on step two by default, because step one takes real effort and step three requires somebody to actually think about the stakes.
The Cookie Banner Problem
Worth naming the failure mode from the other direction, because plenty of friction protects nobody.
Cookie consent banners are the best example anyone has built.
They interrupt every single visitor, on every single site, to get a click that almost nobody reads and that mostly gets given under duress. The regulation was meant to protect people and what shipped just trained everyone to dismiss it without looking.
That's what happens when friction gets applied uniformly instead of proportionally.
Everybody pays the interruption, nobody collects the protection. Two seconds a page adds up to an enormous amount of nothing.
Friction has to be rare to work. Once it becomes ambient, people stop seeing it, and you've spent your interruption budget on air.
The Default Moved
Something changed in the last couple of years though.
Friction is now removed almost by default. The tool writes the code before you've thought about the approach. The assistant drafts the email before you know what you wanted to say.
Most of that is fine and I use all of it. But some of those steps were doing work, and I never sat down and decided to remove them. They went on their own.
Same shape as every other convenience that quietly costs you something, pointed this time at the people building instead of the people using. Every step you remove was there for a reason, even when the reason was accidental, and the reason leaves with it.
The Question Worth Asking
Before removing a step, ask what it was protecting.
Nine times out of ten the answer is nothing, and you should remove it without a second thought. Most friction in most products is accumulated cruft, and the anti-friction crowd is right about the overwhelming majority of cases.
But the 10th time, that step is standing between somebody and a very bad morning.
I'd rather ask the question and find nothing than skip it and find out later. It costs about thirty seconds of thought and the failure mode on the other side is somebody losing work they can't get back.
The Thanks You Never Get
The strange part about protective friction is that it's invisible when it works.
I have never seen anyone praise GitHub's delete flow in public, and I've never received an email about a confirmation dialog that stopped somebody wiping a production table. The good outcome is that nothing happens, and nothing happening generates no feedback at all.
Which means the pressure runs entirely one direction.
Complaints about an annoying step arrive reliably, while the person the step saved has no idea it happened and never writes in.
So the friction gets removed, and it looks like an improvement, and it is an improvement right up until the day it isn't.