RoadHero

Thesis Project, Civic Reporting App

My thesis project. I designed and built an iOS app that turns spotting a pothole into a one-tap report, with a vision AI model running on the phone that watches the road while you drive. There is a companion web dashboard for city ops people, and the whole thing was built solo over six months.

Role: Sole Designer and Builder (UI, UX, Brand, App, Dashboard, Model)
Year: 2026
Services: Product Design, UX, UI, Brand, AI Builder
Industry: Civic Tech, Mobile
Duration: 6 Months (Thesis)
Deliverables: iOS App, Web Dashboard, Brand System, Trained Vision Model

Scroll Down

Challenge

For my thesis I wanted to design a civic reporting app that people would actually use. The official channel for hazard reporting in most cities is a 311 web form, and it loses on both sides. The person reporting the pothole has to know the cross street, fill out a form, and then they never hear back. The city employee on the other end gets hundreds of reports a week and most of them are duplicates or blurry photos of streets they do not own. I had to design something where both sides actually wanted to be there.

Approach

I designed the citizen side around agency, not duty. You earn XP, you climb seven tiers from Street Scout to Street Hero, you watch your city get better in numbers you can see. To make it work without asking people to do extra work, I trained a small vision AI model on a public road damage dataset and ran it on the phone itself. When you drive with the app open, it watches the road through the camera and submits reports for you. On the city side I designed a separate dashboard where AI verifies and deduplicates incoming reports before a human has to look at them.

Outcome

I built the whole thing solo using Claude Code as my coding partner. An iOS app for the citizen side, a web dashboard for the city side, and a vision AI model trained on the road damage dataset that runs on the phone in real time. None of it is in production with a real city. It is a thesis prototype, but it is a complete one, and it works end to end on my own car drives.

The Two Sides

I designed two products that share one set of data.

The phone app and the dashboard are different products because they are for different kinds of work. The phone is a one-tap moment for someone walking down the street or driving home from work. The dashboard is a long sit-down for a city employee reviewing what came in that day. Trying to make one screen do both would have made both worse.

RoadHero mobile home screen — Citizen side, home

RoadHero city operations dashboard reports list — City side, reports queue

The Design Decision I Argued With Myself About

The AI watches. You drive.

The big technical move in this project is that the phone runs a vision AI model in the background while you drive. I trained the model on a public road damage dataset, exported it for mobile, and wired it up so it analyzes camera frames a few times a second. When it sees a pothole or a crack, it makes a report with the GPS coordinates and submits it on your behalf. You never had to do anything.

The harder design question was what to do when the model detects something. The temptation, for engagement reasons, was to ping the driver. Confetti, a little bell, a popup saying you just earned 50 XP. I argued against this and ended up suppressing all in-drive feedback. The reason is that if you train people to look at their phone when they hear a chime, you have made the road less safe in the name of fixing the road. The phone stays silent. The reward fires when the drive ends and you are parked. That is the only correct trade.

RoadHero driving mode UI — Driving mode, intentionally quiet

The App

Five tabs and one verb.

The whole product is built around reporting a hazard. Home shows your reports, the map shows your neighbours' reports, the leaderboard shows whose reports beat yours, the rewards page shows the tier you are climbing, and the profile is where you tune how the AI watches the road. I kept the nav small because the people I designed this for are not power users.

Profile

RoadHero deduplication queue — City side, deduplication queue

Designing For The City Side

The queue arrives already cleaned.

If the citizen side works well, the city side gets buried in reports. A lot of them are duplicates because three different people drive past the same pothole. A lot are blurry. A lot are not the kind of thing this city handles. So I built two AI checks that happen before a human ever sees a report. The first one asks the AI to look at the photo and confirm there is actually a hazard in it. The second one asks whether a new report is the same hazard as one already in the queue, based on the photos and the GPS coordinates. By the time a city employee opens the dashboard, the queue is already a lot smaller and the photos that are left are real.

RoadHero analytics dashboard — Analytics view for a city operations team

Brand

Built to feel like a civic medal, not an arcade game.

Civic tech all looks the same. Trustworthy boring blue, a stock photo of a smiling commuter, a generic mark that could be any city department. Every one of those products gets ignored. I made the opposite call. The brand uses a charcoal, warm gold, and cream palette. Gold leans on thousands of years of "this is valuable" priming so the reward feels earned, and cream over white because the app sits in your hand outside a lot, and cream still reads at the same contrast but does not burn in sun glare.

Brand system, charcoal and warm gold over cream

Palette

Charcoal, Gold, Cream

I picked gold for the reward colour because gold has thousands of years of "this is valuable" behind it. The reward feels like a civic medal instead of a video game level up. Cream over white because the app sits in your hand outside a lot, and cream still reads at the same contrast but does not burn in sun glare.

Severity

Not the traffic light.

For the hazard severity ramp I avoided the green, yellow, red traffic light pattern. That reads as do and do not, which is the wrong mental model. I used a muted teal up to a dark red, which reads as how bad. Critical is dark red, not pure red, because pure red banners everywhere stop meaning anything.

Type

System fonts for everything that has to read fast.

I used the device system font for every screen that the user is actually reading. No custom typeface, no licensing tax, no jarring fallback render. The brand moments like the splash, the tier medallions, and the leaderboard pills carry the personality. The rest of the app is built to be invisible.

The Big Calls

Decisions I would defend in a critique.

Each of these had a cheaper or easier alternative I argued myself out of.

The model runs on the phone, not in the cloud.

A cloud model would have been easier to build because I could update it without re-releasing the app. The reason I trained one that runs on the phone is that cars drive through dead zones all the time. A cloud model would miss hazards in tunnels, on rural roads, or anywhere the cell signal drops. It also means the camera frames never leave the phone unless a hazard is detected, which is a cleaner privacy story to tell anyone using the app.

I used Claude Haiku for the soft AI work.

Beyond the vision AI model that detects hazards, there are two other AI tasks. One asks whether a submitted photo is actually a hazard. The other asks whether two reports are the same pothole. I could have trained classifiers for both but I had no labelled data and I am one person. Instead I let Claude look at the photo and answer with a confidence. It works well enough that I would not change it for v1.

Gamification on a civic app, despite the convention.

Civic tech designers usually argue that gamification trivializes serious infrastructure. The counter argument is that the existing 311 channel generates almost no engagement, and a fix rate of nothing is the worst possible outcome. I designed seven tiers from Street Scout up to Street Hero. The top tier takes weeks of real use, which means anyone who hits it has actually been reporting hazards for a while, which is the point.

Two separate products instead of one website.

The faster version of this project would have been a single responsive website. I split it into a native iOS app and a separate web dashboard because the camera frame analysis I needed to do on the phone does not work well in a browser, and the dashboard runs on city employee laptops where installing native software is a non starter. Two products with shared data was slower for me to build but better for the people using each side.

No mid-drive reward feedback. Ever.

The whole rest of the app has confetti and tier-up animations because they are fun. In driving mode all of that is suppressed. If the AI spots a pothole while you are driving, you find out about it when you park. Rewarding people for spotting hazards while they are moving teaches them to look at the phone. That is the worst possible thing this app could do.

Things I Tried And Dropped

The path is more interesting than just the destination.

Three things I tried and ended up cutting.

The tiny version of the vision AI model.

My first instinct was to ship the smallest possible model because I wanted the app to start fast and not eat battery. The smallest version of the model I trained worked but missed too many real potholes. The one that ships is bigger than I wanted, but it is the size that actually catches hazards. The tiny version is still bundled as a low-end-device fallback.

Detecting hazards from how the car shakes.

A team in Boston tried this in 2012 with a project called Street Bump. They used the phone's motion sensor to detect when the car hit a bump. The problem they ran into is that a manhole cover and a pothole feel the same to a motion sensor, so they got a lot of false positives. I went with the camera instead. It costs more battery, but the false positive rate is much lower because I can actually see what I am tagging.

Push notifications when a nearby hazard gets detected.

I thought about pushing a notification any time someone reported a hazard near you. I cut it for the same reason I cut the mid-drive feedback. You do not want users to associate the app with chimes and pop ups, especially while they are driving. Notifications are reserved for the end of a drive and the weekly leaderboard.

6 Months
solo, thesis

1 Vision AI model
trained from scratch

What I took away from this project.

Designing a product where safety and engagement pull in opposite directions taught me how to argue for the unfashionable choice. Suppressing all in-drive feedback was the right call even though it makes the gamification feel quieter. The harder lesson was that an AI feature is only as useful as the moment of trust around it, which is why the city dashboard has two AI passes before a person ever opens a report.