Travel and Safety
EyezUP
A road safety application that helps prevent distracted driving
Key outcomes
- Delivered a dependable safety product through careful and thorough testing
- Tested the product thoroughly against its goals before launch
- Found and resolved problems early, keeping the launch on track
The problem
A young driver with a phone within reach is a young driver at risk. Each year around 421,000 people are injured in crashes that involve a driver who was distracted in some way. EyezUP set out to quiet the phone while the car is moving, so that attention stays on the road, and to do it without cutting the driver off from a real emergency. It also had to give parents a way to help from a distance, which meant reaching across both iPhone and Android and holding firm on each.
What I did
- Worked out exactly how the application should limit the phone, and, with just as much care, how it should step aside the moment a genuine emergency arose.
- Brought an unusually wide set of parts together, the iPhone and Android applications, the device management that enforced the rules, and the Laravel and Python services behind them, so they acted as one.
- Shaped the controls that parents would use, so a parent far away could still feel in charge of their child’s safety.
- Gave testing extra weight around the emergency cases, since that was the part where getting it wrong mattered most.
Why it was tricky
This is an application that deliberately takes control away from the driver, so it had to be firm and fair in equal measure. It needed to hold its line against distraction, yet never stand between a driver and a real emergency, and it had to behave the same way on very different phones. That balance ran through the whole project.
How it turned out
The application was delivered across mobile platforms and is live at eyezupapp.com. It gives parents a practical way to reduce phone distraction for young drivers, while still allowing for genuine emergencies.
A sample of my work
Illustrative only. It contains no confidential client information.Risk and issue log
A record of how I tracked the risks, assumptions, issues and dependencies on a project where safety was essential.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | The phone restriction must never prevent a genuine emergency call. | High | Project Manager and mobile leads | Addressed. The emergency exception was built and tested first, in a dedicated round of testing. |
| D1 | Dependency | The rules must work in exactly the same way on both Apple and Android devices. | High | Apple and Android leads | Being tracked. The behaviour on both types of device is reviewed every week. |
| A1 | Assumption | Parents sign up and adjust the limits from the online dashboard. | Medium | Product team | Confirmed with the client before the work began. |
| I1 | Issue | The locking behaved inconsistently on older Android devices. | Medium | Testing team | Resolved before launch. |
A sample of my work
Illustrative only. It contains no confidential client information.Release readiness checklist
The checklist I worked through to release a safety application, with extra care around the emergency cases.
Before release
- Test that the phone limits work while the car is moving
- Test that a genuine emergency is never blocked
- Confirm the same behaviour on Apple and Android
- Agree what a successful result looks like
Release
- Release to a small group of families first
- Check the controls that parents use from a distance
After release
- Open the application to everyone
- Watch closely and support families