Agency on Loan: Designing UK Products That Can Be Handed Back

Every pattern we lean on assumes the person at the screen is the one doing the thing. Menus, checkouts, filters, inline validation, confirmation dialogs: all of them presuppose a human with a live intention, walking a flow they can see and stop. Delegation removes that assumption without removing the human. When a customer in Leeds asks an assistant to chase a refund, renew a domain or move money between two accounts, they are no longer the operator. They are the principal, and the product is acting on their behalf.

That distinction sounds academic until the first thing goes wrong. A task completes that nobody quite intended. A subscription renews at the wrong tier. A payment lands against the wrong invoice. The user is then asked to explain what happened using an interface designed for someone who was present the whole time. This is the gap that a delegated interface has to close.

From instruction to intent

A delegated request is compressed. The sentence sort out my broadband contains dozens of decisions an agent will take on the user's behalf: which tariff, which contract length, whether to accept an early termination charge, whether to escalate to a complaint. Traditional UX optimised the number of steps to reach a decision. A delegated interface optimises the clarity of the boundary within which decisions may be taken.

In practice that means designing the brief, not the journey. The user sets the remit; the product shows the remit back in the language of consequence rather than the language of permission names. Spend up to a certain amount. Contact this supplier. Do not change the direct debit. Those are designable statements. Scope: billing.write is not.

Consent that survives a chain

Modern agents rarely act alone. One assistant calls another service, which calls a third. Each hop is a place where the original intent can drift. UK teams already have a useful reference point here: the open banking regime, which forced explicit, time-bound consent and periodic re-authentication into mainstream account-to-account journeys. The lesson worth carrying over is not the specific cadence but the principle that consent has an expiry and a visible owner.

Three practical requirements follow. First, consent should be scoped to an outcome rather than to a system. Second, it should be revocable from a place the user can actually find, not buried three settings levels deep. Third, revocation should be retroactive in effect: withdrawing permission should stop work in flight, or at least surface what is already underway.

The audit trail is an interface

Most organisations can produce a log. Very few can produce a receipt. A log records events for engineers; a receipt explains actions for the person whose name is on them. The distinction matters because delegated work is judged after the fact, often weeks later, frequently during a dispute.

A workable receipt answers four questions in plain English: what was done, on whose authority, at what cost, and what changed as a result. Confirmation of Payee gave UK banking a familiar shape for this in the payments context, and the same instinct generalises. If a user cannot reconstruct the story of a delegated task without contacting support, the interface has failed, however complete the underlying telemetry.

Handback without a restart

The hardest moment in delegation is the handover back. Ideally it never happens; in reality it happens constantly, because every real task eventually meets an edge case. The design question is whether the return feels like a continuation or a punishment.

Good handback preserves state. The user arrives at the precise decision that stalled the agent, with the context already assembled: the options considered, the one recommended, the reason it stopped. Nothing is lost, nothing is repeated. Bad handback drops the user at a home screen with a generic error and invites them to start again.

It helps to think in tiers of escalation. At the lowest tier the product notifies. At the middle tier it asks, presenting a bounded choice. At the top tier it blocks and waits, because the consequence is too great to infer. Deciding which tier applies to which action is a design decision, and arguably the most consequential one a product team will make in this space.

A working checklist

• Name the principal, not just the account. Delegated actions should be attributable to a person, with the agent's role clearly subordinate.
• Express scope as outcomes and limits. Amounts, counterparties, time windows and prohibitions, in the user's words.
• Make expiry visible. Every delegation should show when it lapses and what happens when it does.
• Provide a receipt per task, not a log per system. Plain language, four questions, exportable.
• Design the stall. Decide in advance which ambiguities trigger a question and which trigger a stop.
• Preserve state through handback. The user should never re-enter information the product already holds.
• Offer a single kill switch, and honour it immediately. A panic button that takes effect next working day is not a kill switch.
• Test with people who do not trust the product yet. Delegation anxiety is the dominant emotion in the first session.

Regulation points the same way

The UK regulatory backdrop is converging on these questions rather than away from them. Consumer protection rules on unfair commercial practices, the Information Commissioner's expectations around automated decision-making, and the Consumer Duty standard in financial services all assume that people can understand and challenge what was done in their name. None of them prescribe an interface. All of them require one.

That is the opening for design. Compliance will produce a disclosure; good design will produce comprehension. The teams that treat delegation as a distinct interface paradigm, rather than an extension of the settings page, will be the ones whose users are willing to lend them agency a second time.