Designed friction in systems sounds backward in a culture that treats speed as proof of progress. Products compete to remove clicks, shorten waiting, anticipate decisions, and make every path feel effortless.
Much of that is good design. After all, nobody needs extra steps just to prove that a system is serious. Confusing forms, needless approvals, repeated data entry, hidden menus, and slow workflows waste time without improving judgment.
Yet friction can serve another purpose. At the right moment, a little resistance creates enough space for someone to notice what is about to happen.
That pause can surface a consequence, force a review, separate an impulse from an action, or return a decision to the human before the system carries it forward. For that reason, friction is not automatically good, but it is not automatically failure either.
Designed Friction in Systems Can Act as a Guardrail
In physical environments, a guardrail does not exist because movement is bad. It exists because movement near an edge carries different consequences from movement across open ground.
Digital and automated systems need the same distinction. Changing a display preference, for example, does not deserve the same resistance as deleting years of records, moving a large amount of money, changing security permissions, or approving a high-impact automated action.
Because the stakes differ, the path should differ too.
Good Friction Appears Where Mistakes Become Expensive
Protective friction belongs near choices that are hard to reverse, easy to misunderstand, unusually consequential, or vulnerable to habitual clicking.
- Money: transfers, recurring charges, purchases, or account changes.
- Identity and access: passwords, permissions, authentication, account ownership, or sensitive credentials.
- Privacy: data sharing, tracking, public visibility, or information retention.
- Destructive actions: deletion, reset, overwrite, or permanent removal.
- High-impact automation: decisions affecting another person, financial exposure, security, safety, or material rights.
In those moments, slowing the user slightly can be a feature rather than a defect. The delay earns its place because the consequence is larger than the inconvenience.
The right friction makes the consequence harder to miss, not the task harder to complete.
Not All Friction Is the Same
This distinction matters because “add friction” is terrible design advice on its own. Systems already contain plenty of friction, and much of it deserves to disappear.
A disciplined approach separates three categories: waste friction, protective friction, and exploitative friction.
Type 01
Waste Friction
Waste friction consumes effort without protecting judgment, safety, understanding, or accountability.
Duplicate entry, needless waiting, confusing navigation, redundant approvals, and poorly designed workflows belong here.
Type 02
Protective Friction
Protective friction creates a useful pause when the cost of a careless choice is meaningful.
Confirmation, review, reauthentication, visible consequences, and deliberate checkpoints can serve this role.
Type 03
Exploitative Friction
Exploitative friction makes the user’s preferred or safer action unnecessarily difficult while making the system’s preferred action easy.
Hidden cancellation, obstructed privacy controls, confusing opt-outs, and asymmetric consent belong here.
The Design Rule Is Simple
Once those categories are separated, the design objective becomes clearer. Instead of trying to make everything frictionless, the system can remove what wastes time, preserve what protects judgment, and eliminate what traps people.
In practical terms: remove waste, preserve protection, eliminate exploitation.
Protective Friction and Dark Patterns Point in Opposite Directions
Friction can protect people, but it can also be used against them. A service that makes joining easy and leaving difficult is not creating a thoughtful checkpoint. It is creating asymmetry.
Likewise, a platform that makes privacy-invasive choices effortless while hiding safer controls behind several menus is not protecting judgment. Instead, it is steering behavior through inconvenience.
The Direction of the Friction Matters
The Federal Trade Commission has described manipulative interface practices often called dark patterns, including designs that can push or trick consumers toward choices they may not otherwise make.
Therefore, friction cannot be judged only by whether it exists. The more useful question is who the friction protects and what behavior it makes easier.
Protective friction: makes meaningful risk easier to notice before the user proceeds.
Exploitative friction: makes refusal, cancellation, privacy, reversal, or exit unnecessarily difficult.
A seatbelt and a maze both slow movement. However, only one is designed around the person’s safety.
Designed Friction Keeps Humans in the Loop
Automation becomes risky when a person remains formally responsible while the system no longer creates a meaningful moment for human review.
A manual checkpoint can help, although it should not appear after every automated action. If people have to approve hundreds of trivial decisions, review becomes routine clicking rather than real oversight.
A Useful Checkpoint Must Change the Decision
A meaningful review gives the person enough information to notice what matters, enough authority to stop the process, and enough time to consider an exception.
By contrast, a checkpoint has little value when the only practical option is to press “continue.” In that situation, the system preserves ceremony rather than judgment.
This connects directly to Keeping Humans in the Loop . Human oversight works only when the person can still see, question, and intervene.
Friction Can Interrupt Default Drift
Defaults are useful because they prevent people from rebuilding routine decisions from scratch. However, the same convenience can make an old choice continue long after the context that justified it has changed.
A subscription renews. Permissions stay open. An automated workflow keeps running. A setting chosen years ago still governs behavior because no one has been asked to reconsider it.
Some Decisions Need to Be Reopened
Periodic review can be useful when the stakes are meaningful and the original conditions may have changed. For example, a system might ask whether a recurring permission, payment, data-sharing choice, or automation rule still reflects the user’s intent.
Still, constant reconfirmation would be a mistake. Too many prompts create noise, and users eventually learn to dismiss them.
Therefore, timing should follow consequence. The more serious the decision and the more likely the context has changed, the stronger the case for reopening it.
This principle sits beside When Systems Make Decisions for You , which examines how defaults, ranking, recommendation, and automation can move decisions upstream before the user reaches the final button.
Use More Friction as Consequences Become Harder to Reverse
The strongest reason to introduce friction is not discomfort. It is consequence.
Reversible, low-stakes actions should usually stay fast. Nobody needs a miniature ceremony to rearrange a playlist, change a visual preference, or undo a trivial setting.
Once an action becomes hard to reverse, however, the design standard should change.
Reversibility Should Change the Interface
When an action can be undone easily, a system can afford to move quickly. If recovery is expensive or impossible, confirmation becomes more valuable.
Uncertainty Should Change the Interface
Routine behavior under stable conditions may need little interruption. An unusual amount, unexpected location, sensitive permission request, or abnormal automated recommendation may deserve more review because the usual pattern no longer provides enough confidence.
Consequence Should Change the Interface
As the potential harm rises, optimizing only for speed becomes less defensible. Money, privacy, identity, access, safety, and decisions affecting other people deserve more deliberate design than a low-stakes preference change.
Importantly, that does not mean high-stakes systems must become frustrating. It means the moment of judgment deserves the same design care as the moment of action.
AI Systems Need Friction Where Confidence Can Outrun Understanding
Generative AI makes this argument more urgent because fluent output can collapse the distance between question and action. A draft appears immediately, a recommendation sounds complete, and code can be generated before the operator fully understands what it does.
Speed itself is not the problem. The issue appears when speed removes the moment where uncertainty would otherwise become visible.
Use Review Where the Stakes Rise
Low-risk drafting, brainstorming, or transformation may need very little friction. By contrast, consequential outputs should trigger stronger verification before they move into execution.
Depending on the context, that could mean reviewing sources, confirming assumptions, inspecting sensitive actions, or requiring a second approval when the risk profile changes.
The NIST AI Risk Management Framework emphasizes governance and risk management around AI systems. Although it does not prescribe one universal confirmation pattern, its broader logic supports a central Tech as Discipline principle: controls should match the consequence of failure.
Good AI design should not interrupt people simply to prove that humans are involved. Instead, it should create friction where human judgment can still improve the outcome.
How to Design Friction on Purpose
The goal is not to add steps everywhere. It is to place resistance where that resistance earns its keep.
Groundwork Friction Test
-
What failure are we trying to prevent?
Name the actual risk instead of adding a generic warning. -
How costly is a mistake?
The greater the consequence, the stronger the case for deliberate review. -
Can the action be reversed?
Easy recovery reduces the need for interruption. Irreversibility increases it. -
Does the friction improve understanding?
A useful pause should make the consequence clearer, not merely add another click. -
Can the user still refuse?
Protective design preserves exit, override, reconsideration, and cancellation. -
Who benefits from the delay?
If the friction mainly keeps the user trapped rather than protecting the user from harm, the design deserves scrutiny.
Four Practical Rules for Designed Friction in Systems
1. Name the Consequence
Confirmation language should explain what is actually about to happen. For example, “Are you sure?” is weaker than a clear statement identifying what will be deleted, transferred, exposed, authorized, or made permanent.
2. Make the Safe Exit Visible
A protective checkpoint should not trap the user inside the action. Cancel, pause, return, or revise should remain clear and easy to find.
3. Match Friction to Risk
Not every action deserves the same warning. If every decision looks urgent, users learn that none of the warnings deserves much attention.
4. Design for Attention, Not Compliance
A checkbox does not prove meaningful review. Neither does a long notice that almost nobody can process in the moment.
Instead, good friction creates a clear decision point. The goal is not to prove that a user technically consented. It is to improve the chance that the user understood what deserved consent.
Designed Friction Completes the First Tech as Discipline Arc
This argument closes a useful sequence inside Tech as Discipline.
The Cost of Convenience: What Gets Removed
The Cost of Convenience asks what disappears from the person when technology removes effort that was also building awareness, judgment, or skill.
When Systems Make Decisions: Where Authority Moves
When Systems Make Decisions for You asks what happens when recommendation, ranking, defaults, and automation move decisions upstream.
Designed Friction: Where the System Should Pause
This piece answers the next question: where should the system deliberately slow itself down so the human can still see the consequence before the path becomes automatic?
Together, the three pieces establish a broader rule. Technology should reduce unnecessary human burden without removing the moments where judgment, responsibility, and authorship still matter.
Further Groundwork
→ The Cost of Convenience: What Automation Removes That You Still Need
→ When Systems Make Decisions for You
→ The Structure of Control: Automation, AI, and Human Authority
The Groundwork: Slow Down Where It Matters
Designed friction in systems is not an argument for making technology harder to use. Rather, it is an argument against treating speed as the only measure of good design.
Waste should disappear. Confusing forms, duplicate entry, hidden settings, needless approvals, and workflows that force users to solve problems the system should have solved upstream all deserve removal.
Protective pauses are different. A destructive action may need confirmation. A serious permission may deserve review. A recurring default may need to be reopened when conditions change. Likewise, an automated recommendation with real consequences may need a human checkpoint.
Good systems therefore know two things at once: when to get out of the way and when not to.
A system that cannot slow down at the right moment is not frictionless. It is missing a brake.
Groundwork Architecture
What Holds Designed Friction Together
Protective friction is not arbitrary resistance. Instead, it is structure placed where the cost of an unexamined decision exceeds the cost of a brief pause.
Primary Core Principle
Structure Is Mercy
Structure Is Mercy argues that systems should absorb preventable failure before individuals have to absorb the full cost themselves.
In this context, a confirmation, review step, reauthentication request, or visible consequence can protect a person from an error the system already knows may be hard to reverse.
The point is not more bureaucracy. Instead, it is better placement of responsibility.
Good structure creates resistance where resistance protects the person.
Primary Condition · Contains
Boundaries
Boundaries determine where speed, automation, convenience, and system authority should stop.
Here, a boundary becomes visible as friction: a review requirement, an override point, a permission gate, a consequence notice, or a moment where the system returns the decision to a person.
Without those limits, low-stakes interaction patterns can spill into high-stakes decisions without changing form.
The path should narrow when the consequence widens.
Supporting Conditions: Discernment separates friction worth removing from friction worth preserving. Meanwhile, Accountability ensures that a protective checkpoint still has a person or institution responsible for what happens after the system pauses.
Explore the Groundwork Daily Core Principles and Conditions Architecture .
Receipts
- Federal Trade Commission. FTC guidance on dark patterns examines interface designs that can trick or manipulate consumers into choices they may not otherwise make. This supports the distinction between protective and exploitative friction. Review FTC guidance on dark patterns .
- National Institute of Standards and Technology. The NIST AI Risk Management Framework provides a governance approach for identifying, measuring, managing, and governing risks associated with artificial intelligence systems. Review the NIST AI Risk Management Framework .