Capture only when safely stopped.
Prompts discourage chasing or confrontation. Emergency help is a separate route, not a promise made by the reporting flow.
UI/UX design handout · Mobile app concept
A concise guide to Roadwatch’s citizen-reporting experience and the separate reviewer workspace: the visual language, task structure, key components and safeguards behind the screens.
01 / Product principles
The concept separates what a citizen submits, what a reviewer verifies and what an authority may later do. Each step needs its own plain-language status.
Prompts discourage chasing or confrontation. Emergency help is a separate route, not a promise made by the reporting flow.
Incident type, location and time are reviewed alongside a photo. People can correct details before sharing.
Submission, review, evidence verification and authority action are distinct. A verified report does not imply enforcement.
02 / Visual foundations
The restrained dark surfaces keep incident information legible; yellow marks the primary action, progress cue and important point of attention.
#111614Page canvas#242D27Cards and status rows#FFE052Primary actions#F4F6EFHigh-priority textBold sans-serif headlines communicate the action quickly, even in a stressful context.
Short labels and explanatory copy clarify what will be shared and what happens next.
03 / Typography
A bold sans-serif voice helps a report feel clear at a glance. Labels and status language do the detailed work.
04 / Layout patterns
The reporting flow repeats clear surfaces, compact controls and one dominant action. These examples describe the visual rhythm, not a production token specification.
Keep related evidence and incident details together; separate review and submission as distinct steps.
Use a small family of corners across cards, inputs and action controls rather than a new shape on each screen.
Pair every colour or status cue with words, especially for report review and authority handoff.
05 / Reusable patterns
The same compact controls recur through reporting, correction and follow-up. Labels carry meaning alongside colour.
Yellow is reserved for the main action. A quieter secondary control keeps correction available without competing for attention.
Fields should show the detail in plain words and allow correction before the final review.
Step labels prevent a yellow badge or checkmark from implying more than the system knows.
06 / Information architecture
Citizen tasks stay separate from reviewer decisions, while report status connects both sides of the experience.
Start a report, add details, review before sharing, track a submission and find safety guidance.
Inspect media and facts, request clarification, record the decision and leave a visible review history.

07 / Core user journey
A citizen can move from a safe capture to a traceable report. Corrections and failed submissions need routes back, not dead ends.


08 / UX process
The boards document provisional themes, early layout choices and low-fidelity screen logic before the final treatment.
09 / Screen inventory
Eleven citizen screens and two reviewer views cover reporting, correction, tracking, rewards and an emergency-help entry point.



Start a report or review recent activity.
Prompt evidence collection only when stopped safely.
Add type, time and location with correction available.
Make the information being shared explicit.
Track receipt, review and later updates separately.
Inspect evidence and record a decision without implying enforcement.
10 / Visual direction
The charcoal-and-yellow direction is intentionally high contrast, but the interface should not make a submitted report look like a resolved incident.
Yellow leads the eye to the next safe action, the active step and the most important status detail.
Quiet dark surfaces keep evidence readable. Explanatory language carries uncertainty and separates verification from enforcement.

11 / Implementation & validation
The next stage is task-based testing, not a claim of a launched service.
Observe safe-capture comprehension, location correction and interpretation of the review-before-submit screen.
Check whether people distinguish receipt, reviewer verification and any later authority action.
Rewards, report data and street imagery in the concept are illustrative. Real deployment would require policy, operations and accessibility review.