The problem
A child drowning is fast and silent. There is no shout, no splashing, and the gap between someone slipping out of sight and it being too late is measured in minutes. That is why a product exists that watches the perimeter and the water and sounds a siren on its own.
When the project reached me, that product existed in three technical investor documents and nowhere else. No code, no design file, no logo, no settled name. There was sensor architecture, a state machine, an event taxonomy and latency targets, all written down, and not a single screen.
The cost of that is concrete: a safety product that cannot show itself does not raise money, does not close a condominium deal, and never reaches a home. And when it does, the interface is what decides whether an alarm becomes action or becomes confusion.
The constraints
The decisions
Critical is solid, and the glass stops at the alarm
The system's visual language is liquid glass: translucent panels with blur, floating over a water field that drifts slowly. It works, and it gives the product the calm, expensive air it needs on an ordinary day.
A confirmed critical alert, the emergency screen and destructive confirmations use none of it. They render on solid fills at full WCAG AA contrast.
Glass is for the ambient chrome, not for the moment that matters. Whoever is reading that screen woke to a siren and has a racing heart, possibly in the dark, possibly while running.
Apply the glass across every surface, for the sake of a coherent system. Rejected: aesthetic coherence is cheap next to a second lost reading text over a translucent background.
Colour never carries meaning alone
Every state combines three things: colour, icon and a text label. Green for armed, amber for attention, orange for fault and red for critical all exist, but none of them carries the meaning unaccompanied.
There is the accessibility argument, which would be enough on its own. But there is a worse one: this screen will be read in sunlight, at a glance, by someone in a panic, sometimes on a device that is not the homeowner's. Under those conditions colour is the first information to go.
Rely on colour for state, which would leave the interface cleaner and visually quieter. Rejected: two graphic elements saved against the chance of someone reading the wrong state.
Every critical alert answers four questions, always in the same order
What, where, when, what to do. That sequence, without exception, from the push notification through to the emergency screen.
The order is not style, it is operations. Someone woken by an alarm at three in the morning needs to know which pool to run to before anything else, and in a condominium with several areas the answer to "where" is what separates a useful response from running to the wrong place.
A short message with just the event, and the rest on a detail screen. Rejected: it forces one more tap at the single moment when nobody has time to tap again.
Fault is a first-class state, with a colour of its own
A disconnected sensor, a dying battery, an unresponsive siren and tampered equipment do not appear as a generic error. There is a state called degraded protection, with its own colour, icon and wording, and it can raise a local warning of its own.
A safety system that fails silently is worse than no safety system, because it manufactures false confidence. The family sleeps believing they are covered by a sensor that dropped off three days ago.
Treat a fault as an ordinary notification among the others. Rejected: it disappears into the list, and the day it matters is precisely the day nobody opened the app.
The result
What was delivered is the full language plus three full-screen interface kits: the public site with plans and a sign-up flow, the resident app with arm, disarm, live status, alerts and emergency, and the administrator dashboard with multiple properties, device health and incident history.
Alongside them come the content rules, which on this product carry as much weight as the tokens: tone by severity, the mandatory structure of a critical alert, number and time formatting in Brazilian Portuguese, and the ban on any copy implying the system replaces supervision.
The concrete change is that the product can now be shown. There is an interface to put in front of an investor, a building manager and a family, and it represents the states the system actually has, including the ugly ones.
There are no usage numbers because there is no usage yet. What exists are the latency targets the system declares, and the dashboard was designed to display them, which is the difference between promising reliability and letting someone check it.
Three substitutions were declared rather than hidden: the fonts, the icon set and the brand mark, all provisional and all replaceable without a redesign.
tech sheet
- stack
- Design tokens · CSS · Lucide · HTML
- role
- Visual direction, design system and interface kits