Sometimes the Best Interface Adds Friction

At the start of an evening study session, Iris says: For this session, I want to finish this paper first. Remind me before I open another one. Twenty minutes later, a new result arrives through a standing subscription that alerts her to papers matching her interests. The alert is only a candidate for her attention, not an instruction to abandon the paper. Chapter 20’s rules for when alerts may interrupt still govern whether it should appear now. When Iris finds the result in the reading tool and chooses to open it, a second question arises: may the interface place a reminder in the path of that action?

The channel shows a line beside the action: You asked for a reminder before opening another paper during this session. Beside it are two equally clear choices: Continue current paper and Open new paper now. Iris can take either without a second confirmation, and the source remains accessible. The reminder gives her earlier intention a moment to be considered. It does not decide for her.

The earlier instruction and the present choice both belong to Iris. The system has no independent objective that entitles it to settle the disagreement between them. Its limited authority comes from the intervention she actually requested, not from a judgement that finishing the first paper would be better for her. A standing subscription that authorises discovery is not, by itself, permission to obstruct navigation.

This is a constructed scene, not evidence that a reminder improves concentration. It raises a narrower question:

When may an intelligent channel deliberately make an immediate action harder?

The governing boundary is:

The system may add friction only in service of an objective the user has actually supplied.

That is a necessary condition, not permission to use any means available. The person must also knowingly authorise the type of intervention, the action it targets, its scope and duration, and a way to override or revoke it. Before intervening, the system must be able to establish that the instruction still applies. A remembered goal, an inferred intention or a conveniently phrased suggestion does not substitute for that authorisation.

user-authored goal ≠ system-inferred benefit
support ≠ control

A goal does not authorise every intervention

Iris could say that she wants to finish the paper without asking for any intervention. The channel may then offer an optional reminder rule for her to accept. That rule should not interrupt the ordinary action or repeatedly ask after she refuses. A goal cannot be turned into permission to block navigation, impose a delay, hide relevant sources or monitor unrelated applications. Choosing a goal and choosing a means of pursuing it are two separate decisions.

In the opening scene, she asked for a reminder. That gives the channel authority to show the reminder at the specified point, and nothing stronger. A reminder does not become a confirmation gate because she dismisses it. A confirmation does not become a timed delay because the system predicts greater compliance. A delay does not become a block. Every increase in burden is a change to the contract, and it requires a fresh, explicit decision.

The same boundary excludes goals the system invents. Reading for an hour does not authorise the system to conclude that Iris needs less reading. Opening several sources does not establish a failure of attention. Likewise, a paper, advertisement or retrieved webpage that tells the assistant to enforce a study rule is content, not Iris’s instruction. The authority to introduce friction must trace back to an instruction the user wrote or accepted through an appropriate control channel. It cannot be extracted from the material being read.

The channel can make a proposal, and Iris can accept it, revise it or decline it. Consent to a suggested rule should describe its concrete effect, not merely promise help with focus. Declining should leave the interface usable without repeated requests. Without an applicable authorised rule, the default is ordinary access. The burden of showing that friction is permitted lies with the channel. Iris should not have to prove that she may proceed.

The small contract

The rule needs enough detail to make its effect inspectable, and to let the host enforce it without guessing what Iris meant. For the current session, a small illustrative contract would be:

Goal:          Finish the current paper before opening another.
Target action: Opening another paper in this reading tool.
Intervention:  Show one neutral reminder beside that action.
Override:      Open it now, with no explanation or further gate.
Scope:         This evening's study session and this reading tool.
Expires:       When this paper is finished or the session ends.
Source:        Iris's explicit request at the start of the session.
Authority:     Accepted for a reminder only; no delay or block.

These are explanatory fields, not a fixed implementation schema. They separate a desired outcome from a specific, authorised intervention. Any implementation also needs an inspectable identity and a current status: which accepted version applies, whether it has been revoked or superseded, and which action it covers. The user-facing explanation need not expose a database record. But the system’s decision must be reproducible from the applicable rule and the present context.

A stored contract can remain historically accurate after it expires, but that does not make it active. Chapter 24 distinguished a record’s history from its present applicability and authority. Chapter 25 required session overlays to shed their effects. Both rules apply here. When Iris reaches for another paper, the channel must recheck the contract’s current scope and expiry. Replaying an earlier permission from a cache is not sufficient.

Start with the weakest authorised form

The first intervention should not exceed the form of support Iris requested. Within that form, it should impose no more burden than necessary. In this case, a short reminder beside the ordinary action serves the limited purpose of recalling her earlier instruction. It does not need to interrupt the reading view, start a countdown, require a reason for proceeding or move the original action out of reach. This is a rule about authority, not a prediction that minimal reminders are always the most effective technique.

A different contract could authorise a confirmation, an extra step or a short delay. These are not interchangeable versions of the word reminder. They create different costs in time, attention and accessibility, and they do not always fall on a single scale from weak to strong. Each needs its own explicit authorisation and a meaningful bypass. The channel must not test progressively heavier interventions because Iris keeps proceeding past the original one.

Sometimes the requested support is a stopping point rather than a gate. If Iris asks for a notice after a set of three papers, the channel can mark the boundary: That is the set you chose. Continue? But unless she has asked for a second confirmation, the channel should not make the next paper conditional on answering that question. The stopping point comes from her plan, not from a hidden system judgement about how much reading is enough.

Choosing a less burdensome authorised intervention does not establish that it will help. Research on voluntary commitment devices has found behavioural effects in particular settings, including smartphone-use limits. Those results cannot be transferred directly to this reading reminder or treated as a measure of Iris’s welfare. Cass Sunstein’s analysis of sludge also cautions that added steps impose costs even when their purpose sounds defensible. HCI research on deceptive design describes how obstruction and persistent nagging can serve interests other than the user’s. The proposed contract is meant to set a boundary around such costs. Its effectiveness and acceptability would still have to be tested.

The reason stays visible

When friction appears, Iris should be able to see three things: the action that triggered it, the instruction that authorised it and the scope in which it applies. You asked for this reminder during tonight’s study session before opening another paper is a checkable explanation. If the current rule has already expired, or the requested action falls outside its scope, there should be no reminder to explain.

You are getting distracted again is a different kind of message. It offers a diagnosis, and so turns a scoped request into a judgement about the person. Even if she opens several papers, that observation cannot supply the missing authority.

The wording should report what the contract says without arguing that Iris is wrong to override it. A reason becomes cosmetic if the channel displays her instruction but makes Open now visually subordinate, hard to reach by keyboard, unavailable to assistive technology or slower with each repetition. Equal access to the alternatives is part of what the contract means in practice. Recording an override field is not enough.

authorised friction
+ visible reason
+ easy override
+ explicit expiry

These properties must belong to the same intervention at the moment Iris meets it. She should not have to visit settings to discover how to bypass a reminder, what it applies to or when it ends. If the provenance or validity of the contract cannot be checked, the safe behaviour for this optional reading aid is to omit the extra friction, not to hold her action while the system guesses. Requirements for ordinary accessibility and source fidelity apply independently of the friction rule.

Override changes this action, not the goal

Suppose the new paper contains the missing premise for the one Iris is reading, or evidence that changes whether it is worth finishing. She chooses Open new paper now. The action proceeds immediately, with no second prompt defending the rule she has just bypassed. A reminder designed around yesterday’s plan must not trap her when new evidence changes the task.

That choice is a local exception to one intervention at one moment. It does not show that Iris has abandoned the goal, withdrawn the contract, prefers distraction or lacks self-control. The system may need a narrow mechanism to stop the same reminder from reappearing immediately for the same action. Retaining a longer-term judgement about her behaviour is a different operation, and it needs its own justification.

Three decisions remain distinct:

override this intervention
≠
revise or revoke the rule
≠
change the goal

Iris may make any of these explicitly. Open this paper now bypasses the present reminder. Stop showing this reminder revokes the intervention within the stated scope. I am changing tonight’s plan changes the goal. The interface must not merge these commands. A bypass cannot become a lasting preference update, and revocation must take effect in queued and cached decisions as well as on the current screen.

The override must be accessible and easy at the point of intervention. It should work for mouse, keyboard and assistive-technology users, be understandable without answering a justifying question, and not be hidden by manipulative visual emphasis. It should not require a trip through settings or impose a greater cost on later attempts. If the reminder component cannot provide an accessible bypass, the system should fall back to the ordinary action rather than enforce the contract through an inaccessible interface.

Repetition prompts reconsideration, not escalation

Several overrides may suggest that the rule is no longer useful. They do not, however, reveal Iris’s motive or establish what change she would want. She may be following citations she needs to finish the first paper. A repeated override is evidence that the present reminder has been bypassed. It is not a measure of impulsivity, and it is not consent to stronger friction.

If appropriately retained and authorised, this evidence can support a question. The channel can ask at a natural break: Keep this reminder, change it, or remove it? The prompt should be rare, easy to dismiss and separate from the action she has already chosen. The example’s three-override trigger is an illustrative threshold chosen for the fixture, not a validated rule about when people should be asked. An unanswered prompt does not suspend access or renew consent.

Repeated overrides do not authorise a stronger delay or block. Nor should the system quietly move towards such a rule while treating Iris’s exceptions as evidence of a personal defect. Chapter 25’s boundary applies: behaviour produced under an intervention carries that provenance. It is evidence about those interactions, not an independent vote for more control.

If Iris declines a proposed revision, the revision does not happen. If she asks not to be prompted about it again, the channel should honour that request within the stated scope. Lowering an inference’s confidence while continuing to push the same rejected restriction would preserve the proposal by a hidden route. The system also needs to distinguish a declined new proposal from revocation of an existing contract. The first leaves the current authorised rule as it was. The second ends its authority.

Expiry is part of the permission

The reminder in the worked contract ends when Iris finishes the paper or closes the study session, whichever happens first. Both are conditions on the rule’s lifetime. They are not claims about Iris’s character or success. If completion cannot be observed reliably, the system may ask whether she is finished, or honour an explicit end-session action. It must not assume that a silent interface means an unfinished goal is still active.

A different rule might end at a stated time, at the end of a review or when an incident closes. The relevant event and its source should be specified when the rule is accepted. If expiry cannot be determined, an optional intervention should not continue indefinitely by default. An unfinished goal is not authority to extend a short-lived reminder.

Expiry ends the rule’s current authority, not necessarily the historical fact that Iris requested it. Whether that fact remains stored is a separate retention decision, with its own scope and justification. An expired rule cannot be revived just because retrieval finds the earlier instruction. A fresh session cannot inherit it unless its authorised standing scope genuinely includes that session.

Ending an intervention must also end its unapproved effects on future policy. An expired reminder cannot survive as a stricter default, a diagnosis assembled from overrides or a silently renewed contract. A queued or cached reminder must be invalidated when the rule ends. Records of actions taken under it must keep that provenance, if their retention is separately authorised. This is the same indirect-effect problem described in Chapter 25, now applied to a user-authored friction rule.

An overlay can activate a rule

A declared mode can indicate when an already authorised rule applies. Suppose Iris accepts: During deep-study sessions, remind me before I leave the current paper. Entering a deep-study session that she has explicitly selected can activate that standing rule. The session overlay supplies the current scope and where the presentation appears. It does not write the rule or extend its target to other activities.

The mode does not create the permission. Without the standing rule, selecting deep study would not authorise a reminder, let alone a block. Nor does a system inference that Iris seems to be studying show that a mode has been selected. A mode change, revoked grant or ended session must also invalidate any reminders that are already prepared, before they appear.

Iris may separately ask for unrelated recommendations to stay out of the reading view until the current paper is finished or the session ends, with direct access to sources preserved. That would be a different rule, specifically authorised as a presentation rule. It cannot be inferred from permission to show a reminder, applied to every service by default, or widened from hide suggestions in this view into prevent opening other papers. Selecting a mode, delivering a notice and restricting an action are different powers.

The sequence is therefore:

user-supplied goal
+ authorised intervention
+ matching current scope
          ↓
temporary friction
          ↓
override or expiry

An overlay applies these inputs. It cannot invent an objective, broaden the target action or upgrade the intervention.

When her instructions conflict

Iris can ask for new recommendations to stay out of the reading view until the current paper is finished. She can also ask for every new consensus result to appear immediately. A new result may satisfy both rules at once. If scope and explicit precedence do not settle the conflict, the channel should expose it: You asked to hold recommendations here and also to show this result now. It should allow the access she requested without silently inventing a ranking of her preferences, and without using the conflict to justify a stronger restriction.

Scope can also be uncertain. Opening a second paper may be necessary for the first task rather than a diversion. Iris’s reminder contract is deliberately about the observable action opening another paper, not an inferred label such as getting distracted. If a proposed rule instead targets unrelated browsing, the system must show how it decides relatedness and what happens when it cannot tell. Ambiguity does not license broadening the contract. In this optional setting, uncertainty should leave the ordinary action available.

These cases separate permission from success. An authorised reminder may fail to help Iris finish her paper. An unrequested restriction may keep her on the first paper and still exceed the channel’s authority. Conversely, rapid overrides may be the right response to newly discovered evidence. Completion, compliance, the absence of complaints and fewer opened tabs are each poor substitutes for measuring whether the intervention served her declared purpose without taking away meaningful choice.

The examples establish no measured benefit, including any effect on wellbeing. They make a narrower set of design obligations inspectable: applicable user authorisation, correct target and scope, an accessible immediate override, a visible reason, timely revocation and expiry, and no unauthorised promotion of policy. These are necessary checks on the mechanism. Whether it helps people, compared with a simpler interface, remains an empirical question.

A proposed test: help without taking control

A first experiment would invite readers to set a specific, short-lived reading goal, then opt in separately to the permitted reminder. It would compare three conditions: an ordinary reading interface, a reader-controlled goal note that never intercepts navigation, and the accepted point-of-action reminder. Any stronger confirmation or delay would need its own separately authorised study condition. It cannot be assigned to unsuspecting users in the name of testing friction. The study would use the same materials and planned tasks, counterbalance order where possible, and include trials where the second paper is genuinely necessary to finish the first.

Evaluate at least four outcomes independently: whether the reader achieves the goal they defined; the time and effort spent navigating or overriding; comprehension and discovery of needed evidence; and the reader’s own sense of control. Audit every attempted intervention for missing or expired authority, false scope matches, inaccessible bypasses, repeated prompting and residue after revocation. Include tests with no contract, a forged instruction embedded in a paper, ambiguous session boundaries, contradictory rules and a cached reminder prepared before its expiry. Do not count fewer opened links as success on their own. The hypothesis is that a user-authorised reminder might help some people keep to their plans without harmful interference. This chapter reports no such comparison and no such result.

Running it

Running it. npm run example:personal -- ch25 in the reference implementation (ernanhughes/project-language) establishes the reminder contract and reports what the host permits. npm run example:personal -- all also records three overrides during an invented architecture review. That review is a separate fixture from Iris’s evening paper-reading scene, and neither is an observed user session. The run uses a scripted model stand-in.

What it shows: the fixture represents the contract as an explicit act with a goal, target, intervention, override, scope, expiry and source. Its host rule selects a reminder with an immediate override and refuses a stronger confirmation. One override changes neither the goal nor the contract. After three scripted overrides, it raises a proposed keep, change or remove question, without escalating to a delay or block. The temporary contract ends with the review in the example. These are behaviours of supplied records and deterministic checks. They are not evidence that an AI inferred the right intervention or that a real person accepted it.

What it does not show: whether the reminder improves goal completion, concentration, learning, autonomy or wellbeing, or whether a reminder is preferable to an unobstructed link and an optional goal note. The proposed three-override prompt threshold and the ordering of interventions have no measured support here. The example does not demonstrate accessible behaviour across devices, live notification handling, actual time-based expiry, protection from forged external instructions or enforcement across services. A receipt reports a host decision for a scripted action. It is not a human outcome.

Beyond this reading tool

Chapter 25 made communication fit the present without turning a temporary condition into a personal property. Here the person can deliberately authorise a moment of friction in service of her own plan. That authorisation must remain smaller than her general freedom to navigate. Goal, intervention, scope, override, revocation and expiry are distinct parts of one checkable contract. That such support might help is a hypothesis. That it must not exceed its authority is a design boundary.

Even within one reading tool, the mechanism controls only the actions the tool can actually observe and mediate. Iris’s evening also includes news, video and messages, perhaps on other devices. Her one-tool reminder does not automatically gain authority in those services. Nor does a service’s inability to enforce it justify covert monitoring or a stronger substitute. An interoperable rule must describe which actions a service can recognise and which intervention it can offer. It should not carry along an unnecessary history of the times she overrode it.

The next question is what may travel. Can Iris carry a small, explicit boundary into another service without exporting the behaviour that came before it, changing its scope or granting the new service permissions it never received? Chapter 27 moves from an authorised intervention in one interface to the narrower problem of applying a declared contract across boundaries.

References

• Sunstein, C. R. (2019). Sludge and Ordeals. Duke Law Journal, 68(8), 1843–1883. (Background on the costs of deliberately introduced friction; not evidence about this proposed reminder.)
• Gray, C. M., Kou, Y., Battles, B., Hoggatt, J., & Toombs, A. L. (2018). The Dark (Patterns) Side of UX Design. Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems, 1–14. DOI: 10.1145/3173574.3174108. (Background on deceptive and obstructive interface patterns.)
• Hoong, R. (2021). Self control and smartphone use: An experimental study of soft commitment devices. European Economic Review, 140, 103924. DOI: 10.1016/j.euroecorev.2021.103924. (An example of measured behavioural effects in a different voluntary commitment-device setting.)