Perceev
A road-safety companion for the one operator who can’t look twice — the driver. Speed, upcoming signs, forward-collision and lane-keeping, each pared to what reads in the half-second a moving driver can spare.
A glance too long is the hazard
Most apps compete for attention. A driving app has to do the opposite — it earns its place only if it costs the driver less attention than going without it. The operator’s eyes belong on the road; anything that pulls them off for a second is, in this context, the risk itself. That single constraint governed every decision in Perceev.
The brief was personal. The client, based in France, had been in a minor accident, traced it back to its cause, and wanted a tool that kept ordinary drivers inside the basics — current speed limit, the signs and signals coming up, a warning when the car runs over the limit, and an alert for what’s closing in ahead. A safety net for the parts of driving attention quietly drops.
So the working principle was set before a single screen: optimise for time-to-comprehension, not completeness. One message per moment, large enough to read without a second look — because the second look is the thing the product exists to prevent.
An idea with no picture of itself
The client arrived with the what and none of the how. He could describe the behaviour — watch the road, warn the driver — but had no notion of what the product should look or feel like: how the car should be drawn, where the logo sat, what point of view the driver should be looking from. There was no reference app to point at and say “like that.”
That gap was the actual commission. Turning a one-sentence safety idea into a real digital product meant inventing its entire visual and interaction language from scratch — the perspective, the car, the colour semantics, the typographic hierarchy, and the handful of components everything else would be built from.
Put the driver inside the windshield
The choice that made the rest cohere: render the road from the driver’s own point of view — a chase-cam looking down the lane at the car ahead — so the screen mirrors what’s through the glass instead of asking the driver to translate a top-down map. The on-screen scene and the real scene line up, which is what lets a half-second glance land.
With the perspective fixed, colour carries the message so words don’t have to.Teal means clear and active — your speed, your lane, you’re fine. Red means act — brake, danger, close. The driver doesn’t read the screen so much as register its colour, which is the whole point.
Same screen, two states — and you can tell them apart from the passenger seat, which is the bar.
One number does the heavy lifting
Glanceability is a hierarchy problem. Speed is the hero — the largest element on the screen, because it’s the one value a driver checks most and the one the law cares about. Everything else is peripheral: the upcoming sign, the time, the lane beam, the collision cue sit in support, sized so they’re available to a glance without competing for it.
Night was a design requirement, not a preference. A bright screen at night blinds the operator it’s meant to protect, so the driving default is the dark surface — speed and cues glowing off near-black, the cabin kept dark. The day and night surfaces aren’t a cosmetic theme; they’re a safety boundary the rest of the system had to honour.
Running before the driveway
Perceev rides alongside a device, so the connect flow had to be the least interesting part of the experience — find, pair, done. The goal is a driver who never thinks about setup: the safety layer is already live by the time the car leaves the driveway, because asking someone to fiddle with pairing once they’re moving would reintroduce the exact risk the app removes.
Even the failure state pulls its weight. “No device found” is written as a safety message, not a dead error — it tells the driver plainly that the assist isn’t active yet and what to do about it, in the interface’s own voice, never apologising and never vague.
A language built to be read at speed
Because there was no precedent to borrow, the whole thing had to be invented as a system: a tight colour vocabulary with fixed meanings, a road-sign set drawn to one grid, a type ramp anchored by a single giant numeral, and a small family of components reused across every state. The screens above are assembled almost entirely from the primitives below — that economy is what lets a one-month build still feel like one product.
Colour is the message
Two semantics do the work: teal = clear / active andred = act / danger. Indigo and violet carry the brand; two neutral surfaces draw the line between day and night driving.
The road-sign vocabulary
Recognition beats labelling, so the system leans on signs every driver already knows — redrawn to one geometry, one stroke weight, one red, so they read identically whether they sit in the HUD or surface as an upcoming-signal cue.
Type, anchored by one numeral
The ramp is deliberately top-heavy. The speed reading is enormous and tabular so the digits never shift; everything below it steps down hard, because in a glance interface a flat hierarchy is a failed one.
800 · tabular
500 · mono
700 · uppercase
700 · uppercase
500 · mono
The HUD components
A small family, each rebuilt here from the system — the same parts the screens are assembled from.
The perspective primitive
The signature element: the driver’s-eye scene. The same primitive renders every state — only the colour of the road changes. Teal when you’re clear; red when the gap ahead demands the brake.
Day & night, one component
Every surface was specified twice — a daylight skin and the near-black night skin that’s the driving default. Same hierarchy, retuned contrast. (The same discipline this portfolio now ships with its own light / dark switch.)
Foundations
Soft on the chrome, fully round on pills and the assist toggle.
A flat 8-pt rhythm — enough scale for a glance grid, no more.
State changes snap (~140ms). A safety cue can’t wait for an animation to finish.
A sentence, turned into a shipping app
Concept to product in about a month, as the sole designer — the visual language, the interaction model, and the component set all originated here. The work carried forward into engineering and was built in Flutter, shipping on bothiOS and Android.
Roughly four months on, the client got back on a call and demoed the working app — his idea, born out of a real accident, now running on a phone. The honest read is qualitative: there’s no controlled in-traffic study behind it, and that’s the next thing this project would earn. What it does show is a clean 0→1 — a vague brief taken to a coherent, buildable product, and a client who saw his own idea come back to him as something real.
What a v2 would have to earn
The whole product rests on a claim — that these states read at speed — and that claim was validated at a desk, not behind a wheel. The discipline I’d add next is in-context testing: legibility checked while actually in motion, at night, in glare, because a safety claim is only as good as the conditions it was tested under. The visual language has aged well; the proof is the part still owed.