At quarter to eleven, the counter at a municipal office began to fill. One resident needed to renew a permit for her street stall; a father needed proof of residence for a grant application; two older people were asking about appointments made by phone. A red notice appeared on the clerk's screen: to reduce fraud, the council had decided that every request must be confirmed with a code sent to a mobile phone. The decision followed several impersonation attempts. On paper, it looked sensible. On that particular morning, it stopped people without a phone, people who had changed numbers, and people who shared a device with family.
The problem was not that staff wanted to ignore security. A decision designed for a real risk had turned a protection into a narrow gate for a public service. Repairing it required more care than switching the control off. The office needed to understand the harm it was meant to prevent, the people it was excluding, the alternative checks that could offer reasonable assurance, and the record needed to keep the same mistake from returning in the next rollout.
Start with the scene, not a defence of the system#
When a digital rule blocks a task, two opposing responses often arrive quickly. One says residents must adapt because the technology has already been chosen. The other says every control that causes friction should disappear at once. Neither is very helpful to someone standing at the counter. The first mistakes the presence of a control for its quality; the second can reopen the exposure that prompted the original decision.
When a digital rule blocks a task, two opposing responses often arrive quickly. One says residents must adapt because the technology has already been chosen.
The coordinator asked staff to record, for one week, the cases that could not finish their transaction. She did not begin by asking who had made an error. She asked what was happening. They recorded the task, the exact point of failure, the alternative offered, the extra time involved, and whether the person could complete it later. A clear pattern appeared. Phone codes worked for requests started at home by people with their own device, but predictably failed for urgent renewals, shared phones, and recent number changes after a move. Some residents received the code on a relative's absent phone, which created an uncomfortable dependency and reduced privacy.
That record changed a scattered complaint into a design question: what evidence does the service actually need to confirm who is making this request? A code sent to a phone is one possible piece of evidence. It is not identity itself. Keeping those two ideas separate makes it possible to find alternatives without pretending that every route carries the same risk.
Separate the purpose from the chosen mechanism#
The rule had been created to stop someone with basic details about another person from requesting documents or changing an address. That was a legitimate purpose. The chosen mechanism was a message to a registered number. Over time, the mechanism was treated as the purpose: no mobile, no transaction. That sentence avoided the harder question of which combination of evidence might be sufficient in a different circumstance.
The office sorted transactions by impact. Downloading a copy of non-sensitive information could use a simpler check. Changing an address, applying for a benefit, or accessing children's data required stronger verification. Not every action deserves the same threshold, and not every resident can meet one threshold with one tool. This classification does not lower security. It focuses security where impersonation would do the most harm.
For instance, a person attending in person with an official document and knowledge of a recent application could begin a permit renewal. The system flagged the action for a second review before the final document was issued. A change with financial consequences required an appointment for in-person verification with two independent checks. People with digital access could still use the phone code, an authenticator application, or an institutional credential. The repair was not about making every path easier. It was about making each response to risk explainable.
Build an exception that does not become a hidden shortcut#
The word exception can make people nervous because it suggests privileges granted without a rule. Yet a public service must account for situations an automated flow cannot understand. The decisive difference is whether an exception has a purpose, a limit, and a reviewable trace.
The office created a short assisted-service process. A staff member selected the reason for the alternative — no personal device, a recent number change, a technical incident, or an accessibility need — and recorded the checks completed. The system did not collect an intimate story or demand an explanation of someone's life. It retained only what was needed to understand the decision. Where the transaction carried higher risk, a second staff member confirmed the step. Once completed, the request entered a review queue with a maximum response date.
This avoided a familiar temptation: demanding more personal information to compensate for a badly designed rule. A resident did not need to explain why she shared a phone with her son. It was enough to recognise that a phone could not be the sole access condition and to apply a proportionate check. Dignity is not decorative politeness. It makes reliable information more likely because people can understand why it is being used.
Test the repair with people carrying the friction#
Before changing the portal, the council held three short sessions. It invited counter staff, an older residents' association, a mediator from an area with frequent moves, and a digital-accessibility practitioner. They were not asked to approve an attractive mock-up. They worked through scenes: a person loses a phone on the day of an appointment; a carer accompanies her mother but cannot receive her codes; a resident must correct a record before a deadline expires.
The discussions found details that a technical document had missed. The message, “you have not passed validation,” made people feel suspected. It was replaced with wording that explained available options and expected timing. The alternative appointment route was hidden at the bottom of a page, so it moved beside the phone field. Staff asked for a two-sentence script so that explanations would not vary by desk. Each adjustment came from an observable scene, not an abstract preference about interface design.
They also measured what happened next. Did the alternative actually finish the transaction? Did fraud attempts increase? Did unanswered reviews accumulate? A repaired control must generate information that can be evaluated, rather than only relief on launch day. If a second review takes three weeks, the office has moved the harm instead of reducing it.
Turn repair into institutional memory#
A mistaken decision can return when it exists only in the memory of people who experienced it. The coordinator therefore asked for an accessible decision note: identified risk, original rule, evidence of exclusion, alternatives considered, change selected, review owner, and signals that would require reconsideration. It was not a report written to defend the office in an audit. It was learning material for the next project.
The note carried one useful warning: fraud indicators alone cannot judge a control. The office also needs to observe abandoned requests, referrals to the counter, added service time, and complaints that a transaction cannot be completed. If a measure reduces one kind of fraud while multiplying incomplete cases for people with fewer resources, the outcome deserves public discussion, not a single success percentage.
The team agreed to review the change after three months. They would invite the people who had tested the scenarios again, check whether the exception categories still made sense, and examine a sample of assisted decisions. Review is not an attempt to prove that the council was right the first time. It keeps correction possible before a buildup of complaints turns a small defect into broad mistrust.
Before imposing its next digital rule, the team can ask a simple question: how will a person complete this task when they cannot use the mechanism we imagined? The answer will not always be immediate. But preparing proportionate, visible, reviewable routes means security can protect access to the service as well. In one afternoon, any office can choose one of its controls, observe five real cases, and write down what it protects, whom it blocks, and what legitimate route it offers. Risk does not disappear. The institution regains responsibility for deciding with evidence and repairing a good intention when it becomes a barrier.
