SafeNet — Emergency Response App

Onboarding does more than create an account. It completes the product setup in a single flow, so the app is fully ready the moment a user reaches the home screen. The sequence is: create account, verify email via OTP, add emergency contacts, and write custom alert messages per emergency type. Nothing is deferred to later.

Account creation collects a first name, last name, email address, phone number, and password. The phone number field defaults to the Ghana country code (+233), removing a step for the primary market. Email OTP verification follows immediately, with a resend option and a numeric keypad presented inline rather than redirecting to the system keyboard.

The contact setup step ("Who should we call?") prompts users to add their emergency contacts during onboarding rather than after. Name, phone number, and relationship type are collected here. Getting this done upfront means the app can fire contact notifications from the very first alert, not only after a user remembers to set it up later.

The message setup step ("What will your contacts receive?") lets users write a pre-set message for each alert type: Police, Fire, and Medical. Each field shows a character count (160 max) and placeholder text to guide tone and format. This is where the emergency message feature is seeded. Onboarding is the right moment to capture it because the user is already thinking about who they'd contact and why. The messages can be updated at any time under Settings.

The home screen reduces the entire emergency decision to a single choice: police, fire, or medical. Each service is presented as a full-width card with a distinct colour (red for police, green for fire, blue for medical) so a user under stress can act by recognition, not reading.

Tapping a card does not open a confirmation dialog. It immediately fires a coordinated set of background actions: dials the nearest station, shares the user's GPS location, and notifies their emergency contacts. Every design decision on this screen was evaluated against one principle: does it reduce cognitive load, or add to it? Confirmation prompts were removed. Service descriptions were kept to one line. The bottom navigation was stripped to only three tabs.

Once an alert is triggered, the app transitions to an active call state. The call bar is pinned at the top of the screen, always visible and always accessible, showing the station name, live call timer, and controls for video, audio, and ending the call. The pinned bar was a deliberate choice over floating or collapsible alternatives: in an emergency, a user should never have to hunt for the end-call button.

Below the call bar, a scrollable station list surfaces all nearby stations with ETA chips. The active station is visually distinguished with a light red background and a 4px left accent bar. Inactive ETA chips are grey; colour is reserved as a signal for urgency and active state, not decoration. A scroll fade gradient at the bottom implies additional stations below the fold without requiring a scroll indicator.

The top of the screen carries an amber instruction: "If no response, dial 911# via USSD." Amber was chosen as a warning signal, present and readable, but not competing with the red urgency of the active state above it.

The call bar also surfaces a video call toggle. In situations where a voice description is insufficient (a fire with an unclear spread, an injury that needs visual triage, a location that's hard to describe), switching to video gives the responder direct visual context. Specificity saves response time, and a dispatcher who can see the scene makes faster, better-informed decisions than one working from a verbal account alone.

When an alert fires, the app doesn't just call a station. It simultaneously notifies the user's saved emergency contacts. The contacts screen is a dedicated tab in the bottom navigation, giving it the same weight as the home screen. Contacts are listed by name and relationship, with avatar initials for quick recognition. A search bar and a prominent add button keep management frictionless.

Each contact stores a name, phone number, and relationship type. The edit screen is intentionally minimal: three fields and a delete action. The relationship label is the key detail; it gives context to whoever receives the notification, so a sibling or parent knows immediately who is alerting them and why. Keeping the relationship field as a dropdown rather than free text reduces the chance of errors under stress.

During onboarding, users write a custom emergency message for each alert type: Police, Fire, and Medical. These can be updated at any time under Settings. When an alert fires, that message is automatically sent to every saved contact alongside the user's live location. No typing required under pressure. A user might set their police alert message to read: "I'm in danger and need help. My live location is attached, please call me or come now." Their fire alert might read: "There's a fire near me. I've alerted the fire service. Please stay clear of [area]." Giving users control over this message at setup means the right information reaches the right people the moment it matters.

USSD works on any phone with no internet connection, no app installed, and no data balance. For an emergency product targeting Ghana, where data coverage is uneven and feature phones are still common, this is not a fallback. It is the most defensible feature in the product.

The USSD flow presents a numbered menu: 1 for Fire, 2 for Medical, 3 for Police. The user dials a short code, selects their emergency type, and the system routes the alert without requiring anything beyond a basic cellular signal. This positions SafeNet as genuinely inclusive in a way pure-app competitors cannot claim, and it reframes the product from "a better emergency app" to "an intelligence layer that works regardless of the device in your hand."

There is one hard constraint worth naming honestly: USSD cannot transmit GPS location. The protocol carries only text, there is no mechanism to attach location data, and cell tower accuracy in Ghana can mean a radius of several kilometres in rural areas, which is not useful for dispatch. The app version gives you live GPS. The USSD version requires a human in the loop. The design addresses this directly: the USSD flow prompts the user for their location as part of the session, asking for a nearest landmark, area, or major road.

The station list problem is solved through backend intelligence. Showing every police station in Ghana would be overwhelming and useless without location context. Instead, the system uses the caller's phone number, which is passed automatically at the start of every USSD session, to look up their stored location. Every time a registered user opens the SafeNet app, their current GPS coordinates are silently updated on the backend. When they dial the short code, the server uses that last known location to pre-filter the station list to their area with no extra step required. For users who have travelled or haven't opened the app recently, a "Different region?" option sits at the bottom of the list, letting them manually select their current region before seeing a filtered station list. For completely unregistered users dialling in for the first time, the flow starts with a region selection menu (16 options matching Ghana's regions) before showing local stations.

The app and the USSD flow are not two separate products. They share the same backend. The more a user engages with the app, the smarter and faster the USSD experience becomes. SafeNet gets more useful the more embedded it is in a user's life, even when they rely solely on USSD.