Maps: Route Control for Drivers
A case study exploring how drivers can personalize route recommendations without increasing navigation complexity.
Role
Sole designer; research, interaction design, AI-assisted prototype build.
Duration
One week intensive
Deployed
Stack
FigJam for research and ideation.
Cursor to build and iterate.
Material Design 3 via Google’s Material Web components.
React and Vite, Leaflet for map rendering, OSRM for routing, OpenStreetMap/Nominatim for places and geocoding. Routing and place data are real; traffic is simulated.
What Drivers Actually Want
Two independent sources grounded the problem: an existing Reddit survey and discussion thread (44 responses, run by another community member and analyzed as secondary research), and an original review of roughly 400 Google Play reviews across phone, tablet, and car.
44
Responses from an existing community survey, analyzed as secondary research
48%
Reported wrong directions or unsafe routes
56%
Rated frustration 4–5 out of 5
~400
Google Play reviews analyzed across phone, tablet, and car
Reviewers independently described Maps changing their route mid-drive without warning. Several used the language of consent, unprompted, across a period of months.
Affinity Map
Affinity mapping reduced 16 research categories to 8 core insights; the 3 below connect directly to the capabilities built.
Competitive Audit
Assessed whether Google Maps, Waze, or Apple Maps had already addressed this problem.
Lets a user block a specific road
Confirms before rerouting
Google Maps
No, category-level only
Time-limited only, a Reject button appears with a brief countdown; the reroute applies automatically if not rejected in time
Waze
No, long-requested, unbuilt
No, reports go to human review
Apple Maps
No, manual workaround only
No
No major navigation app allows a driver to block a specific road. Google Maps comes closest on rerouting confirmation, but defaults to accepting the change unless the driver rejects it within a few seconds, a time-pressured opt-out, not an unhurried, equal-weight accept/reject choice. Both gaps defined the design brief.
Research Insights
INSIGHT 1
Users trust their own local knowledge and want to influence routing when Maps doesn't match it.
INSIGHT 2
Users lose confidence when Maps prioritizes speed over safety.
INSIGHT 3
Users need timely, visible guidance; unclear cues increase cognitive load while driving.
Maps Decides, Drivers Comply
Problem statement
Drivers need greater control over route recommendations. Google Maps offers limited ways to personalize routes, which reduces confidence whenever a recommendation conflicts with local knowledge or the situation at hand.
How might we help drivers personalize route recommendations without increasing the complexity of navigation?
One System, Five Capabilities
Five candidate concepts were evaluated on user value and ease of use. All five were selected and combined into a single system, since route creation, selection, saving, and trust function as one continuous flow for the driver.
Concept
Capabilities
Route Creation
Create your own route, pin/reorder stops, snap to roads, drag route, prefer this road
Route Selection
More route options, ranked alternatives, compare routes, explain recommendations
Route Preferences
Avoid/block roads, never use road, road-quality preference, scenic route
Route Persistence
Save custom routes, preserve custom routes, remember preferences, named commute routes
Navigation Control
Route lock, ask before rerouting, reject reroute, restore planned route, audio cue
Each concept was broken into specific, named capabilities.
Initial sketches included the reroute confirmation screen, Accept/Reject buttons and a speaker icon, exactly as later built. Road rules were sketched as a three-state system: Prefer, Avoid, Block. Voice command syntax was specified at this stage: "Avoid [road name]," "Prefer [road name]," "Block [road name]," followed by system confirmation. The third state shipped as Never use this rule, the same concept under a revised label. Live-navigation voice control for road rules originated in this sketch; Iteration 2 testing confirmed it was needed earlier than the build schedule anticipated.
The proposed flow introduces two decision points absent from the current flow: customization before route selection, and the ability to accept or decline changes once navigation has started. Each capability has a corresponding flow.
Design Principles
1. Confirm before acting, no route change without explicit accept/reject
2. Control at the road level, not the category level, Prefer / Avoid / Never use
3. Match Google’s existing patterns before inventing new ones
4. Persistence means the exact path, not just the destination
5. Confirmation must be fast enough to act on while driving
Building Route Control in Cursor
Developed in two phases using Cursor, deployed to GitHub Pages. Desktop Google Maps allows dragging the route line to reshape it; mobile doesn't. The edit flow closes that specific gap. Material Design 3 is implemented directly, using Google's Material Design component repository.
Tech stack
Material Design 3
React
Nominatim
Vite
OSRM
Leaflet
Build phase roadmap
Phase 1: Core Editor
Drag-to-reshape
Snap-to-road
Undo
Route comparison chip
Phase 2: Full System
Recommendations, selection
Preferences, road rules
Persistence, navigation control
AI route assistant
Multi-modal tabs
Engineering constraints
Routing engine limit
OSRM caps route alternatives at 3 and rejects hard road exclusions.
Hard filter rejected
Soft-ranking system
Touch event failure
Leaflet dispatches mouse events only, touch drags didn't register.
Map panned instead
Pointer handlers
I scoped out
Avoiding high-crime areas
No external safety data available
Live construction & closure awareness
Needs real-time data beyond OSRM
Time-of-day "escape routes"
Deferred as a future personalization layer
Voice staging sequence
Text-based assistant
Sketch-stage parsing logic
Live voice input
Added after Iteration 2
"Avoid [road]" / "Prefer [road]" / "Block [road]" → confirms
The features
Drag-drop route editing
Route saving
Preferring, avoiding or blocking a road before driving
Reroute audial consent (sound on)
Prefer, avoid or block a road through audial commands while driving (sound on)
Preferences: Scenic roads, fewest turns, & good quality roads
Always suggests 5 routes (tick icon indicates good quality road)
Renaming saved routes
Note on visual fidelity: Not pixel-identical to the live Google Maps app. Interactions and layout follow Google Maps' patterns; used Material Design 3 component repository. Interaction logic was prioritized over pixel parity.
The prototype
Three Rounds, Thirteen Drivers
Iteration 3 (3 participants)
100% task completion across the full feature set, including voice and onboarding under first-time use.
What Testing Changed
Assumption
Outcome
Drag is discoverable without onboarding
Disproven, onboarding added
Text confirmation is sufficient before rerouting
Refined, moved to voice for speed
Avoid vs. Never use require separate builds
Confirmed as built, 3 of 3 Round 3 participants explained the distinction correctly, unprompted
From Assumption to Evidence
3
Testing rounds
13
Participants total
2
Major design changes driven directly by testing evidence
Prototype vs. Production
This Prototype
Production Google Maps
Places / search
OpenStreetMap + Nominatim
Google Places
Routing
OSRM
Google Navigation SDK
Traffic / live conditions
Simulated
Google Maps Platform (real-time)
Limitations
Small, largely personally-connected testing sample.
Qualitative testing; time and ease metrics not yet captured.
Accessibility audit (contrast, screen reader, ARIA) not yet run.
Next Steps
Broader unmoderated validation.
Quantified time and ease metrics, using the existing tracking sheet.
Accessibility audit.
Defined success metrics (e.g. reduction in manual mid-route correction).
Reflections
Testing validated important design decisions and also found problems. It confirmed that Avoid/Never feature worked as intended in Round 3 and revealed the drag mode issue in Iteration 1.
Technical limits affected the design. OSRM's exclusion limit led to a soft ranking approach instead of giving users controls that the system could not fully support.
Building with AI required clear instructions. I had to turn feedback like "the drag feels wrong" into specific, testable changes.
Working alone in one week meant some decisions, such as the original edit mode, were not tested until Iteration 1. With more time, I would get feedback from another person before building based on an assumption.
AI-based prototyping made it faster to build and test real interactions. Features like route dragging were easier to implement in Cursor than to simulate in Figma.