Product Friction Should Live Where the Risk Lives

Friction Belongs Where the Risk Lives

Good product design does not remove every step. It removes needless effort from the safe, expected path and adds proportional verification where identity, authority, money, property, or safety changes.

The purpose of friction is not to slow people down. It is to make a consequential transition visible, keep the legitimate path usable, and prevent a small failure from becoming an expensive emergency.

Eon founder Rei Vardi made the principle concrete in Episode 116. An approved renter should be able to reach and unlock the correct car quickly. Giving an unapproved person control of that car should be harder. Reporting a flat tire should lead to help more easily than abandoning the vehicle.

The short answer

Put friction at the point where a user gains authority, transfers responsibility, commits money, exposes sensitive information, or creates a difficult-to-reverse outcome. Remove friction from repeated actions after the system already has the information and authority it needs.

Then test both sides. A control that blocks legitimate users may be too heavy or poorly timed. A fast path that hides a dangerous change may be optimizing conversion at the expense of the product.

flowchart LR
    A["Low-risk repeated action"] --> B["Remove duplicate work"]
    C["Identity or authority changes"] --> D["Verify and record"]
    E["Failure begins"] --> F["Guide the safest recovery"]
    B --> G["Measure time and completion"]
    D --> H["Measure false approvals and false declines"]
    F --> I["Measure recovery time and harm contained"]

Friction has three jobs: remove waste, verify consequential transitions, and guide recovery.

1. Start with the consequence, not the screen

Teams often debate whether a flow should have three steps or five before agreeing on what can go wrong.

Begin with the asset, authority, or outcome. What can the user now do that was impossible before? How hard is the action to reverse? Who absorbs the loss if the decision is wrong?

Opening a saved preference is low risk. Adding a driver to a rental car changes who can control a valuable moving asset. Exporting a public image differs from exporting private customer data. Buying an inexpensive consumable differs from sending an irreversible bank transfer.

The interface should reflect the consequence. If two actions carry different harm, giving them identical confirmation may be consistency in appearance and inconsistency in risk.

Rei's first Tesla rental failed because the product treated a high-consequence handoff like an ordinary exchange. The physical key communicated possession. It did not show whether the recipient had been approved, whether another person received the car, or when authority should end.

2. Remove coordination the system can perform safely

Friction is waste when a legitimate user repeats work that the system already completed.

Eon's current site says a customer verifies identity, receives unlock instructions before the rental, and uses the phone as the key. The company also says approved additional drivers can receive separate digital keys. That removes a scheduled owner meeting from the normal path without removing the decision about who may drive.

This is the useful version of automation. The system does not pretend the access decision disappeared. It makes the decision once, binds the result to the appropriate user and vehicle, and avoids asking two people to coordinate the same fact again at pickup.

The product team should be able to name what work was eliminated and what authority remains. If the work merely moved to an owner, support agent, local contractor, or customer, the friction was redistributed rather than removed.

3. Add verification when authority changes

The right moment for friction is usually close to the consequential action.

If another person receives a vehicle key, the product should make the person, scope, and duration visible before access is issued. If a user changes a payout destination, the product should verify the actor before money moves. If an administrator grants a new privilege, the product should show the resulting authority rather than hiding it behind a generic save button.

NIST's Digital Identity Guidelines separate identity proofing, authenticator binding, authentication, recovery, and revocation. NIST is not a product-design manual for every application. Its lifecycle helps expose a common mistake: confirming identity once does not answer every later question about who controls the credential or whether the authority should continue.

Proportional friction may be a fresh authentication, a second approver, a time delay, a review of changed permissions, or an explicit acknowledgement. The control should match the likely harm. It should also explain why the step exists in language the user can understand.

4. Make the safe recovery the easiest visible option

Many harmful outcomes begin without malicious intent. They begin when a person under pressure cannot find a credible next step.

Rei used a flat tire as the example. The renter is away from home. The owner is on a flight. Finding a tow provider, confirming the right tire, paying out of pocket, and seeking reimbursement later may feel uncertain and slow. Leaving the vehicle and continuing by rideshare may feel immediate.

Abandonment can create towing, damage, storage, delay, and more expense. The harmful path wins when the product made it easier.

A designed recovery path tells the renter what happened, which actions are approved, who will pay, how long help should take, and when a person assumes the decision. It preserves the trip record so the customer and operator can later establish what the system knew and did.

The current Eon App Store listing promises human support, and the live site promises 24/7 help by call or text. Those are company service claims, not guarantees of response in every incident. They show why "zero-human" should describe removal of the routine handoff rather than removal of accountable support.

5. Detect the exception before the user depends on the promise

The best recovery often begins before the customer encounters the failure.

Rei says Eon checks connected-vehicle information before pickup and can reassign a renter when the scheduled car is not ready. The company's privacy policy says it may collect vehicle health, diagnostic, location, and trip data.

Telemetry does not prove that a car is ready. It can make some failures visible earlier.

That timing changes the burden. A customer notified at home may adjust. A customer standing beside a locked or unready vehicle is already late. Product teams should measure how far ahead of dependency they detect known failure modes, not only how quickly they respond after a complaint.

The same principle applies to payments, data imports, deliveries, and infrastructure. A system that can predict or detect failure should not wait for the customer to become the monitoring layer.

6. Keep friction out of unread legal text

Terms and policies matter. They allocate responsibility and communicate formal conditions. They are weak tools for guiding a tired person in a live exception.

Eon's current rental terms address license and insurance verification, deposits, mileage, responsibility, and vehicle condition. A renter still needs contextual guidance at booking, pickup, delegation, incident reporting, and return.

The product should place the relevant decision where it occurs. It should say what will happen and why. The full terms can remain available for detail.

This is not an argument for hiding restrictions behind friendly copy. It is the opposite. The consequence should be clearer at the moment of action than it is inside a long agreement.

7. Measure false approvals and false declines

Conversion alone cannot tell whether the friction is well placed.

A fast onboarding flow can approve participants the system cannot serve safely. A heavy identity flow can reject legitimate users, delay travel, create support work, or discriminate through poor data and review design.

Measure the entire decision. Track legitimate completion, time to decision, false declines, successful appeals, unauthorized access, manual-review load, repeat verification, support volume, recovery time, and the value or harm contained by the control.

When a customer is declined, the system should preserve enough information for a lawful, safe, and useful review process. Eon's privacy policy says it may use background information, credit information, and public-record inputs to evaluate eligibility. That is a reminder that product friction can carry privacy, fairness, accuracy, and regulatory consequences. Those questions require qualified review, not an interface shortcut.

8. Design revocation with the same care as approval

Products celebrate entry and neglect the end of authority.

A vehicle key must stop working after the rental. A departing employee should lose administrative access. A lost device should have a recovery path. A former vendor should not retain credentials because the offboarding flow was harder than onboarding.

Revocation also needs a safe sequence. Cutting access at the wrong time can strand a renter, interrupt a safety-critical process, or leave a user unable to retrieve data or property. The system should know what can be revoked immediately, what requires a controlled transition, and what evidence supports the decision.

Google's digital car-key sharing guidance notes that deletion may take time and that some vehicles require another physical or digital key before removal completes. That specific behavior varies by vehicle. The product lesson is broader: a revocation request and a completed revocation are different states.

Where the rule breaks

Not every risk transition needs another screen. Repeated prompts teach people to confirm without reading. A weak confirmation can create the appearance of control while adding little protection.

Some decisions are better handled through safer defaults, limits, monitoring, separation of duties, or delayed execution. Some recovery paths require immediate human judgment. Accessibility may require an alternative to a control that assumes a particular device, language, motor ability, or sensory mode.

The goal is not maximum friction at maximum risk. It is the smallest effective control at the right moment, supported by detection and recovery.

The product should feel fast where the user and system are aligned. It should slow down just enough when authority changes. It should become unusually clear when something has already gone wrong.

Episode 119's [[How to Test a Product Where It Will Actually Fail]] helps move this framework into real-use testing. Episode 100 adds the founder operating-system view. Episode 25 shows how quickly operational design and liability meet in autonomous vehicles.

Sources, method, and updates

This guide synthesizes Rei Vardi's examples in [[E116 Full Transcript]] with Eon's current site, App Store listing, privacy policy, and rental terms. The identity lifecycle comes from NIST SP 800-63-4. The digital-key revocation example comes from Google's current guidance.

AI assisted with organization, source comparison, and editorial review. Dalton Anderson's transcript and the linked primary sources control the factual claims. Refresh the guide when identity guidance, Eon's product model, or the related recovery examples materially change.