Rain had been striking the windows for hours when Samira opened the link the council had circulated on her phone. Her building was not flooded, but the shared garage was, power was flickering, and the alert advised people to leave ground-floor homes. She had two children, a bag of medicines, and little battery left. The screen asked her to create an account, choose a password, enter an address she might be leaving, provide an identity number, and accept three legal notices before it showed whether any accommodation was open. From the kitchen, her son asked where they would sleep. Samira was not failing a digital-skills test. She was trying to get somewhere safe while the service asked her to fit a route designed for an ordinary day.
Public emergency tools usually begin with a legitimate purpose: organise places, prevent duplicate requests, identify who may need transport or food. Trouble starts when that administrative need is placed ahead of the immediate need to get oriented. During a storm, people do not arrive with the same documents, language, charged card, or calm attention for every instruction. Some have left quickly, some are caring for someone, some do not know the city, and many share a phone. Designing for the calm, complete case turns assistance into an obstacle course for those with the least room to manoeuvre. The first question on an emergency interface should not be, “Can you complete this record?” It should be, “Are you safe, and which nearby route can you use now?”
Show shelter before asking for explanations#
Information that saves minutes should come before information that completes a database. An opening screen can show, without prior registration, which shelters are open, their approximate capacity, available accessibility features, enabled transport, and clear guidance for someone unable to travel. It need not promise a bed that does not exist or reveal details that compromise safety. It only needs to distinguish information needed to decide from data needed to manage. A simple map, a neighbourhood list, and a call option may do more than a polished welcome page.
Information that saves minutes should come before information that completes a database.
Booking a place may require data, but it should be requested in layers. Start with what prevents exclusion: how many people are travelling, whether there is a mobility or medication need the receiving site should know, and a way to send confirmation. Later, once the family is on its way and has some stability, identity, an alternative contact, or administrative circumstances can be checked. This order does not lower safety. It avoids mistaking safety for early collection. If a person can only say, “Two adults, two children, we need somewhere dry,” the system should still be able to give useful direction rather than treating that brevity as suspicious.
The language of each step matters too. “Complete required fields” does not explain why the process stopped or how to proceed. Under pressure, long instructions and technical refusals force people to guess. It is better to say, “First we will show open places. Then we can hold a space. If you cannot complete this, tap here or call this number.” The interface must say what follows each choice: whether it is a request, a provisional confirmation, or a handover to a person. Calling a submitted form a reservation may lead a family to stop looking for alternatives. Clarity is not a friendly tone added at the end. It is accuracy about the real state of help.
Language is not a translation detail#
In an emergency, “available in several languages” can mean very different things. It might be machine-translated labels, a guide reviewed by people who know the context, an interpretation line, or a volunteer who answers patiently. One poor choice of word about evacuation, pets, medicines, or documents can change a decision. That is why another-language version should not merely translate the longest form. It must retain the same main routes: find accommodation, request transport, speak to someone, communicate a need, and confirm that a message arrived.
Cognitive accessibility deserves the same seriousness. Someone who is tired, frightened, or has an intellectual disability does not need an explanation with less dignity. They need a sequence that does not require remembering ten things at once. One task per screen, direct verbs, buttons with unambiguous consequences, and the ability to go back without losing what has already been said can make a material difference. The journey should be tested with screen-reader users, older people, families new to the application, and community mediators. Not by asking them to perform panic, but by finding which part of the design demands concentration that cannot be assumed.
Human contact is not automation failing#
Some situations cannot be resolved well by any drop-down list. A parent may not know whether an inhaler counts as urgent medication. Someone may be worried about entering a shelter because they travel with an assistance animal. A person may be avoiding another person and not want to explain why in a public box. When the only exit is choosing the wrong category, a tool turns a care problem into user error. There must be a visible option to speak or write to a person, with an honest estimate of the wait and an alternative when lines are busy.
That contact must have real power to act. A chat staffed by someone who can only repeat the screen is not enough. The human team needs to be able to hold a temporary space, correct a detail, connect someone to transport, request interpretation, and leave a limited note that prevents a family from telling the same story at every handover. It also needs privacy rules: collect only what is necessary, explain who will see it, and do not turn a request for shelter into a record that keeps circulating after the emergency ends. Trust disappears quickly if asking for help means surrendering more intimacy than help requires.
A human alternative should not be hidden as a reward for people who persist. If a portal puts its number in small print at the bottom of a page, it transfers the work of finding help to someone who is already exhausted. It can offer calls, text messages, in-person points, and coordinated neighbourhood organisations, because digital infrastructure fails precisely when there are power cuts, saturated networks, or shared phones. Equivalence matters: the route that does not use the app must lead to the same current information and a comparable response, not to a queue with no visibility.
Confirm, accompany, and learn from the journey#
After pressing “request,” a person needs to know what happened. Useful confirmation includes an easy-to-keep number or name, the assigned site or position in a list, the time of the next update, and what to do if conditions worsen. It should not demand an email address they may be unable to check. It can arrive by text message, an automated call with an option to speak to someone, a consented messaging channel, or a check-in at a community point. If there is no immediate place, saying so plainly and offering a concrete action is more responsible than maintaining a waiting screen that looks hopeful.
The design does not end when the storm subsides. A council can review the journey without blaming the people who used it: how many left before seeing a resource, which languages generated more requests for help, which fields created blocks, how long a human response took, and whether non-digital alternatives received the same information. Those figures should be read alongside short accounts from families, reception staff, and interpreters. A measure of completed forms can hide the people who gave up in the first minute. A good review looks deliberately for that absence.
The next improvement can be small and testable. Before the rainy season, a team can simulate a request with a slow connection, low battery, and three languages; time when the first shelter appears; confirm that a person can call without making an account; and check that the confirmation distinguishes a request from a guaranteed place. It should then publish who will correct each failure and when the test will be repeated. There is no need to wait for a disaster to discover that a password field blocks an exit.
Dignity in an emergency does not mean treating everyone as an exceptional case or giving up on organising scarce resources. It means recognising that organisation must work when people cannot behave like calm, informed users with time to spare. Samira should be able to open the link, recognise a safe route, ask for help in a language she understands, and receive confirmation without giving a screen her whole life story. When an interface makes room for that reality, it does not become less precise. It becomes capable of doing its job when it matters most.
