Rosa logs into the public-housing portal after an alert tells her to book an appointment. Her application has been pending for months, and the appointment may determine whether she can keep the documents moving before her temporary accommodation ends. A consent screen appears before the calendar. The large button says “Accept and continue.” A smaller route leads to settings, where declining certain processing means that appointments are hidden and the application must be restarted through another channel. The screen calls this a preference. In practice, it turns a housing need into leverage.
Choice is not established by counting buttons. It exists when a person can take either route without losing the substance of the service. Rosa may technically be allowed to decline, yet the cost of doing so is delay, repetition, uncertainty, and perhaps a missed appointment. Someone with a printer, flexible work, a private phone, and time to visit an office may survive that burden. Someone caring for children, working shifts, sharing a device, or facing eviction may not. A public digital service should not treat unequal capacity to absorb friction as evidence of free agreement.
Separate the appointment from the optional appetite for data#
Booking an appointment can require limited information. The service needs enough to identify the application, offer available times, and communicate a confirmation by a channel the applicant chooses. It does not automatically need behavioural analytics, promotional messages, broad profiling, or transfers to tools that are convenient for a vendor. When all of those activities are bundled into a single approval, the portal stops asking for permission and starts charging people for access to an essential service.
Booking an appointment can require limited information. The service needs enough to identify the application, offer available times, and communicate a confirmation by a channel the applicant chooses.
The design team should ask a plain question about every field and integration: what fails if the applicant refuses this? If the answer is “the calendar fails,” the team must show why that item is operationally necessary. If the answer is “our analytics supplier receives less information,” it cannot justify blocking a booking. This exercise forces the institution to distinguish a real administrative need from an organisational preference. It also makes vague phrases such as “service improvement” answerable: improvement for whom, using which data, for how long, and with what alternative?
Equivalent refusal means protecting the practical result, not merely displaying a link. A person who declines optional tracking should keep the same queue position, appointment inventory, confirmation notices, and ability to reschedule. They should not be sent to a phone line that closes at noon, required to create a separate file, or asked to repeat evidence already provided. The two paths may differ in data flows, but they cannot differ in dignity or in the chance of receiving help. A refusal route that reliably produces more work for the applicant is a penalty disguised as a setting.
Timing matters as well. Asking for consent at the final moment, after a form has been completed, exploits the fear of losing progress. The portal should allow applicants to save their place, read a short explanation, seek support, and change an optional choice later without resetting anything. An urgent application is a poor setting for making people decode dense legal language. Time to understand is part of what makes consent meaningful.
Test the service with people who cannot afford its mistakes#
Completion rates alone will flatter a coercive design. A dashboard may show that most people accepted quickly and that appointment slots filled efficiently. It will not show how many accepted because they feared a delay, how many abandoned the process, or how many could not understand the consequence of declining. The institution needs to observe the whole journey: the alert, the consent screen, the calendar, a lost connection, a changed preference, an error message, and a request for help.
That observation must include paid testing with people who actually depend on the housing service. Invite older applicants, people who use assistive technology, applicants with limited data plans, tenants who rely on interpreters, parents with little uninterrupted time, and people who have previously had to correct an application. Their role is not to praise the interface. Ask them to book, decline an optional purpose, recover after closing the browser, and seek an explanation. Their accounts reveal whether the portal assumes stable broadband, institutional confidence, and spare time that many residents do not have.
Failure scenarios should be designed on purpose. Suppose Rosa declines analytics, loses her connection on a bus, and returns forty-eight hours later. Is her tentative appointment still there? Does the system demand new information? Does it imply that she caused the failure? Consider another case in which an applicant needs help from an advocate but wants to limit what the advocate can see. Support should make access possible without turning a helper into the owner of a person’s complete housing history. These are not exotic exceptions. They are ordinary conditions that a public service must handle before launch.
Reviewing results by group helps identify a burden that a simple average hides. A two-day delay does not weigh equally on someone with secure housing and someone sleeping on a relative’s sofa. A mandatory call is not equally easy for a person with a quiet private room and for a person using a prepaid phone at work. The point is not to reduce people to fixed categories. It is to notice when a design consistently transfers the cost of privacy to those with the least room to bear it. That pattern is evidence for redesign, not for blaming applicants for failing to adapt.
Make the decision legible and the system bounded#
Before asking for a choice, the portal can provide a compact map with three groups: information essential to the booking, optional information tied to a named feature, and information that is never a condition of access. Each item should state its purpose, recipient, retention period, and withdrawal method. “To improve your experience” is not an explanation because it does not tell Rosa what will happen to her information or what she gives up by saying no.
The technical system must honour that map. An optional measurement tool should not receive an application number, previous address, or household details by default. Access should be limited to named roles; exceptional viewing should leave a reviewable record; and integrations should expire unless the organisation can justify renewing them. A supplier’s default configuration is not a public justification. The agency remains accountable for procuring the tool, connecting it to a housing service, and deciding what it may receive.
Changes need to be visible, too. If an update broadens a purpose or adds a recipient, an applicant should not discover that change when an appointment vanishes. The portal should announce it, preserve the application state while the person decides, and keep the equivalent booking route available. A public change log can record what changed, why it changed, what testing supported it, and which people may be affected. This lets advocates, residents, and oversight bodies examine a decision without relying on rumours or obscure terms of service.
Accountability must repair, not merely explain#
There must be a named role with authority to stop an unnecessary integration, demand an impact review, change a harmful screen, and fund an equivalent channel. Responsibility without authority creates a familiar failure: the technology team points to procurement, procurement points to a vendor, and the service desk tells Rosa to start over. A public body needs a clear owner for the whole route, including what happens after a refusal.
Applicants also need a simple remedy. If declining an optional purpose costs someone an appointment, they should be able to report it online, by phone, or in person without proving technical expertise. The remedy should restore the position they would have held if the defect had not occurred; a complaint ticket is not enough. The agency should then examine cases together: which rule caused the loss, which residents were affected, and what test should have caught it? Repair turns individual harm into a reason to improve the system rather than a footnote in a monthly report.
Public housing can be prompt, secure, and respectful without making agreement a toll for entry. It can use only the information needed for the appointment, keep optional purposes separate, preserve an equivalent route, and test the service with people who most need it to work. The standard is clear: declining a non-essential use must not hide the calendar, erase progress, or require a person to surrender privacy in order to be heard. When it does, the interface is not offering a free choice. It is enforcing a condition that the institution has a duty to remove.
