The checkout line moved quickly until the card terminal asked one shopper for an extra check. She walked to the door for a signal, the code arrived too late, and she paid with cash. Nothing fraudulent happened, yet the manager of the small neighborhood shop wrote the incident down: it was the fourth in two days. She also noted something less visible. Two unusual payments that morning had gone through without a prompt. The question was not whether to choose security or convenience, as though they were rival teams. It was where to spend people’s patience.
That spending can be treated as a friction budget. Every alert, permission request, second confirmation, and delay uses time, attention, and trust. Like any budget, it should not be spent evenly. An extra confirmation can prevent harm that is hard to repair; repeating it for an ordinary purchase can teach people to approve every screen without reading it. Responsible design does not pile up obstacles until it feels safe. It saves friction for moments when the risk, the cost of being wrong, and the difficulty of undoing an action genuinely warrant it.
Watch the workaround before changing the rule#
The shop did not begin by replacing its payment provider. For two weeks, it watched the full path of payments, message-based payment links, refunds, inventory-app permissions, and account alerts. Staff described which steps they skipped during a rush and which ones generated support calls. The answers were uncomfortable and useful. Low-value alerts were dismissed unread; an app requested contact access at installation even though nobody used that feature; and refunds, which could affect the shop’s margin, relied on a shared password written in a notebook.
The shop did not begin by replacing its payment provider. For two weeks, it watched the full path of payments, message-based payment links, refunds, inventory-app permissions, and account alerts.
A friction budget cannot be calculated at a desk without seeing these practices. There is a difference between a stated rule and the work people actually do. When a screen appears at the wrong moment, people create a workaround: they share credentials, leave a session open, accept broad permissions, or ask someone else to approve a prompt. The workaround is not proof that workers are careless. It often shows that the control was placed where it does not fit the job.
Observation also prevents a common error: unusual use is not automatically suspicious. The shop had market days with many rapid purchases and association orders above its usual ticket size. Blocking both would punish familiar customers. A large manual refund to a new account was different: meaningful financial impact, an unusual signal, and poor reversibility once money had left. That was a sensible moment for a second check and a clear record of who resolved it.
Score cost, risk, and reversibility#
For every control, the team used a short worksheet with three questions. What does a mistake cost? What signals make an error or abuse plausible? How far can the result be undone? They did not pretend those answers produced a perfectly precise number. Categories and concrete examples were enough to force payments, permissions, and alerts to be judged by their situation rather than by the habit of enabling every available safeguard.
Cost is more than money. An overbroad location permission can expose delivery routines. An ignored alert can conceal an account used from a new device. A payment block during a busy hour can make someone abandon a needed purchase or lose confidence in the shop. Cost must therefore be considered on both sides: the harm of not checking and the harm of checking badly.
Risk should not be a vague sense that the internet is dangerous. It should be made from observable signals. Changing a supplier’s bank account, approving a large refund on an unregistered device, or granting permanent camera access each offers a reason to pause. Asking for another PIN on a small payment from the same card at the same terminal adds little new information. A good alert explains what changed; a poor alert merely announces that the system is anxious.
Reversibility completes the decision. Some actions can be repaired with a receipt, a phone call, or an inventory adjustment. Others create data copies, irreversible transfers, or records that continue to affect someone. The less reversible the action, the more reasonable it is to slow down, show the relevant information, and offer human review. There is no need to interrogate every sale in order to protect a bank-detail change.
Payments: check the change, not the routine#
The first practical change removed repeated confirmations from low-value in-person payments that had already passed the bank’s ordinary checks. In return, the shop created a clear review step for changed payment destinations, refunds above an agreed threshold, and remote orders with inconsistent details. The screen did not simply say “risk detected.” It showed the amount, destination account, related order, and the reason for a second check.
That specificity matters because it lets staff correct rather than blindly comply. If a manager sees that a refund belongs to a duplicate purchase from a regular customer, she can approve it with a brief note. If the destination account changed after a strange email, she can pause the transaction, call the supplier through a known channel, and record why. The note is not paperwork for later blame. It lets the next shift understand what was checked and learn from a case without reconstructing it from memory.
The budget also included an exit when a control failed. Nobody was left without an option because a code did not arrive. For an in-person purchase, staff could offer cash, immediate transfer, or a short product hold. For a refund, the case could move to manager review without requiring the customer to expose extra information. Security that works only with a charged phone and perfect reception moves all the risk onto the shopper.
Permissions: ask for less, explain the moment#
Permissions exposed another form of wasted friction. The inventory app requested contacts, location, and camera access on its first launch. Staff accepted because they needed to log stock, but nobody understood why that task required their address book. The shop checked the functions actually in use. Camera access became a one-time request for scanning a barcode; contacts and location disappeared from the ordinary setup.
A proportionate permission is requested near the action that needs it, with an explanation a person can test. “Open the camera to scan this barcode” is testable. “Allow access to improve your experience” gives no basis for weighing cost or alternatives. Refusal should also have an understandable result. If manual entry remains possible, the app should say so. Turning a choice into a disguised mandatory permission removes meaningful consent.
The same principle applies inside the team. A person packing orders does not need authority to change bank details; someone handling refunds does not need every supplier record. Separating access reduces the damage of a mistake and reduces the number of occasions that need an important check. Fewer broad permissions mean fewer ambiguous alarms to examine later.
Alerts that arrive with an available action#
The shop replaced its endless notification stream with three alert classes. Informational notices were grouped at the end of a shift: low stock, completed payment, filed invoice. Decision alerts appeared with a bounded action: review a recipient, confirm a refund, verify a new device. Urgent alerts were saved for unexpected access or changes with immediate impact. Each class had an owner and a channel; nothing was merely left pending on the phone of whoever happened to be closest.
A useful alert contains the minimum information needed to act without turning an incident into improvised detective work. It should say what happened, why it is unusual, what approval would mean, and what alternatives exist. It must also admit that the alert may be wrong. Offering approve, pause and review, and mark as expected produces better information than forcing someone to close a window. If the same prompt is marked expected every market Friday, the design should learn that pattern rather than demand limitless patience.
The monthly review mattered. The team counted how many alerts each rule generated, how often they led to a different decision, and how often they interrupted sensitive work. An alert that never changes a decision consumes budget without returning protection. It should be adjusted, grouped, or removed. One that reveals real problems may deserve more context and a support route for the person receiving it.
Make the bearer of the cost visible#
Friction decisions are often made by the person administering a system, not the person waiting, selling, or repairing an error. The shop therefore included a cashier, the delivery worker, and two regular customers in its review. They were not asked to approve a technical policy. They were asked where they lost time, which notices they understood, and what consequences worried them. Their answers differed in useful ways. The administrator feared refunds; the cashier feared locking out an older shopper who could not receive messages; the delivery worker feared permanent location access that stored routes nobody needed.
The result was not a system without controls. It was one able to state its priorities. A second check is accepted when a change can move money, reveal data, or prevent repair. It is avoided when it merely repeats a routine without a new signal. Exceptions are recorded so that someone does not have to persuade every shift from the beginning. Use data is reviewed to see whether a barrier protects people or merely moves effort elsewhere.
A budget to revisit, not a permanent rule#
Before enabling a new verification, the shop now asks one final question: if this measure fails, who pays the price, and can they recover? The question exposes controls that punish people with the least slack as well as controls that protect a genuinely delicate decision. It also recognizes that risk changes. A fraud campaign, a new supplier, or a new feature can move the point at which extra attention is worth requesting.
The next step does not require buying another tool. For one week, record five frictions: one that prevented an error, one that did nothing, one that produced a workaround, one that left somebody without an alternative, and one that helped repair a decision. Then classify them by cost, risk, and reversibility with the people who live with them. That small inventory makes security a practice of concrete care: ask more when the consequence demands it, and leave room for ordinary life to continue.
