Interaction Design — Google Maps mobile route control
Maps: Route Control for Drivers
Component key: INTRO (framing text) · STAT · INSIGHT · QUOTE · TABLE · TIMELINE · LIST · MEDIA
MEDIA — hero shot, prototype on mounted tablet, in-car
Role: Sole designer — research, interaction design, AI-assisted prototype build
Duration: One week, intensive
Stack: React and Vite, Leaflet for map rendering, OSRM for routing, OpenStreetMap/Nominatim for places and geocoding, Material Design 3 via Google’s Material Web components. Routing and place data are real; traffic is simulated.
Deployed: vishakhag19.github.io/Cursor — built and iterated in Cursor
01
What Drivers Actually Want
INTRO: Two independent sources grounded the problem before any design work began: 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 in 24 hours (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
QUOTE (app store, paraphrased): Reviewers independently described Maps changing their route mid-drive without warning. Several used the language of consent, unprompted, across a period of months.
INTRO: Affinity mapping reduced 12 research categories to 7 core insights.
INSIGHT
Users trust their own local knowledge and want to influence routing when Maps doesn’t match it
INSIGHT
Users lose confidence when Maps prioritizes speed over safety
INSIGHT
Timeline is treated as permanent history; any loss feels unacceptable
INSIGHT
Route data must reflect real-world conditions or trust breaks down
MEDIA — Affinity Map
MEDIA — Insights PDF
Competitive Audit
Lets a user block a specific road
Confirms before rerouting
Google Maps / Gemini
No — category-level only
Not documented
Waze
No — long-requested, unbuilt
No — reports go to human review
Apple Maps
No — manual workaround only
No
INTRO: No major navigation app allows a driver to block a specific road or confirms a route change before rerouting. This gap defined the design brief.
02
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?
MEDIA — Problem Statement PDF
03
One System, Five Capabilities
INTRO: Five candidate concepts were evaluated on user value and ease of use. All five were selected and combined into a single system rather than delivered as separate features, since route creation, selection, saving, and trust function as one continuous flow for the driver.
MEDIA — Concept Evaluation table
MEDIA — sketches: route creation flow, save-route modal, saved-routes list, road-rule popup, voice reroute confirmation
INTRO: Initial sketches, completed before development began in Cursor, 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.
Route Management Features
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
MEDIA — Route Management Features PDF
Design Principles
• Confirm before acting — no route change without explicit accept/reject
• Control at the road level, not the category level — Prefer / Avoid / Never use
• Match Google’s existing patterns before inventing new ones
• Persistence means the exact path, not just the destination
• Confirmation must be fast enough to act on while driving
MEDIA — Current Flow PDF + Proposed Flow PDF
INTRO: 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.
TIMELINE — Route Creation Flow
1. Enter start and destination
2. Review the suggested route
3. Drag the route line, or add waypoints individually
4. Each edit snaps to the nearest valid road
5. ETA and distance update in real time
6. Compare the edited route against the original suggestion
7. Save, or begin navigation directly
TIMELINE — Route Selection Flow
1. Enter a destination
2. View the top 5 ranked routes, each with ETA, distance, traffic, and a stated reason
3. Tap a route to preview it on the map
4. Compare trade-offs across routes
5. Select and start
TIMELINE — Route Preferences Flow
1. Open preferences before or during planning
2. Toggle scenic, fewest turns, road quality, avoid tolls/highways/ferries
3. Recommendations re-rank in real time as toggles change
4. Add a rule for a specific road, by name or by long-press on the map
5. Choose Prefer / Avoid / Never use
6. The rule applies immediately and persists across future trips
TIMELINE — Route Persistence Flow
1. From any route, recommended or self-created, select Save
2. Name the route, or accept an auto-generated name
3. Access it later from the Saved Routes list
4. Reopening loads the exact saved path, with no recalculation
5. Rename at any time
TIMELINE — Navigation Control Flow
1. Start navigating on the selected route
2. If the system identifies a possible reroute, it interrupts with a stated reason
3. Two equal actions are presented: Accept or Reject
4. Accepting updates the route and makes “Return to original” available for the remainder of the trip
5. Rejecting leaves the route unchanged and ends the interruption for that suggestion
04
Building Route Control in Cursor
INTRO: Developed in two phases using Cursor, built with React and Vite, and deployed to GitHub Pages. Map rendering uses Leaflet; routing uses OSRM; place search and geocoding uses OpenStreetMap data via Nominatim.
INTRO: Desktop Google Maps allows a user to drag the route line to reshape it; the mobile app does not. This gap explains why Reddit complaints concentrate on phone and tablet use, where Maps relies on alternate routes and “Add stop” rather than freeform drag-to-edit. The edit flow addresses this specific gap rather than introducing a capability absent from Google Maps entirely.
TIMELINE — Phase 1: Core Editor
1. Drag-to-reshape, initially gated behind a separate edit mode, snap-to-road, undo
2. Route comparison shown as a chip (e.g. “+2 min vs suggested”)
3. Tooltips added to Undo, Reset, and Edit/Finish after early testing found the icon-only control row unclear
Phase 2: Full System
• Route Creation — create your own route, pin/reorder stops, snap to roads, drag route, prefer this road
• Route Selection — top 5 ranked alternatives, side-by-side comparison, reasoning shown per route
• Route Preferences — scenic, fewest turns, road-quality preference, and per-road rules: Prefer / Avoid / Never use, triggered by long-press
• Route Persistence — save and preserve a custom route exactly as built, not just origin and destination
• Navigation Control — route lock, ask before rerouting, reject reroute, restore planned route, audio cue
• AI route assistant — parses commands for each rule type (prefer, avoid, never use a named road), then confirms, routed through the same accept/reject flow as any other reroute
• Multi-modal tabs — Drive, Two-wheeler, Transit, Walk, Bicycle, Ride (Transit is a prototype placeholder; the remaining modes route through OSRM)
INTRO: Route renaming was not part of the original scope; the assumption was that a saved route would not require renaming. One participant in Iteration 1 requested it (Section 5), and it was added.
INTRO: Two constraints in the public OSRM instance shaped the design. OSRM limits route alternatives to 3 and rejects hard road-exclusion requests. Generating the 5-route recommendation set required additional motorway-avoiding queries and detour corridors. Avoid and Never use road rules were implemented as soft ranking adjustments rather than hard exclusions, which OSRM does not support. The feature functions as a simple toggle for the user; the implementation underneath compensates for a routing engine limitation.
INTRO: Drag-to-edit exposed a mobile web limitation in Leaflet: the library dispatches mouse events only, so touch drags did not register, and the map panned instead of the route line responding. This was resolved with custom capture-phase pointer handlers. A related z-ordering issue — inactive route lines appearing above the selected route after exiting edit mode — was resolved by calling Leaflet’s bringToFront() method on the active route. A separate defect hid the Undo and Reset controls on mobile, since entering edit mode collapsed the panel containing them; this was resolved with a floating edit toolbar that remains visible independent of panel state.
Scoped Out, Deliberately
• Avoiding high-crime areas: requires external safety data not available in this prototype
• Live construction and closure awareness: requires real-time road data beyond OSRM’s static network
• Time-of-day “escape routes” (multiple saved paths for one commute, selected automatically by conditions): scoped as a future personalization feature, not core route control
INTRO: Material Design 3 was implemented directly rather than approximated. The UI uses Google’s Material Web component library, including its color, typography (Roboto), and shape tokens. Snackbar usage was restricted to match MD3 guidance after an early version over-used them; snackbars now appear only for process errors and in-progress states, such as locating the user, rather than as confirmation for every interaction.
INTRO: Voice followed the sequence established in the initial sketches. A text-based assistant, running full-screen on mobile, shipped first, using the parsing logic specified in the sketches. Live voice input was added after Iteration 2 testing showed it was needed sooner than planned.
MEDIA — prototype screens: Recommendations, Road Controls, Navigation Control confirm state
Note on visual fidelity: this prototype is not pixel-identical to the live Google Maps app. Core interactions and layout follow Google Maps’ existing patterns, and the MD3 component usage is genuine — real Material Web components, real color, typography, and shape tokens. Matching Google’s production design system exactly would require auditing every component against their internal specification; this was not the objective. Correct interaction logic — confirm-before-acting, road-level control, exact-path persistence — was prioritized over pixel parity. The accessibility audit (contrast, screen reader support, ARIA) remains outstanding.
INTRO: Research, interaction design, and implementation were directed end-to-end by one person, using Cursor as the build tool throughout.
05
Three Rounds, Thirteen Drivers
Testing evidence is organized as completion signals, full findings, incorporated changes, and unresolved tension.
3
testing rounds
13
participants total
2
major design changes driven directly by testing evidence
100%
task completion across the full feature set in Round 3
MEDIA — in-car testing photos ×4
TIMELINE — Iteration 1 (5 participants)
1. 4 of 5 completed tasks with help; 1 completed independently
Iteration 1, Full Findings
• Participant 1 (completed with help): drag-to-edit should not require a separate edit mode; the snackbar shown during editing gave insufficient information and disappeared too quickly; suggested the app account for current location rather than only the entered destination.
• Participant 2 (completed with help): encountered bugs; did not understand how the drag points worked for route editing; attempted to rename a saved route, a feature that did not yet exist; had difficulty zooming on mobile; confused “Add stop” with the drag-point editing interaction.
• Participant 3 (completed independently): suggested weather information tied to the remaining route during live navigation; suggested surfacing tourist points of interest during a “trip mode” with scenic routing; suggested color-coding the 5 route options from green to red by speed.
• Participant 4 (completed with help): could not locate the undo or reset controls; considered the AI text assistant unnecessary; mistook the drag points for stops.
• Participant 5 (completed with help): requested a tutorial for the features; considered the AI text assistant unnecessary; requested voice commands during navigation, including for highway exits.
Incorporated After Iteration 1
• Removed the separate edit mode for route editing
• Added a clearer messaging layout introducing route editing
• Fixed reported bugs
• Added the ability to rename a saved route
• Removed the AI text assistant
Note: Participant 3’s weather, points-of-interest, and route color-coding suggestions were not incorporated. They remain open ideas rather than scoped features.
TIMELINE — Iteration 2 (5 participants)
1. All 5 completed their tasks; 2 required help on one task each
Iteration 2, Full Findings
• Participant 1 (completed independently): edit should snap to the road rather than a precise coordinate; the reroute pop-up was not useful, since there was no time to read it; requested voice commands during live navigation; self-reported learning the features quickly; rated Saved Routes the easiest feature.
• Participant 2 (completed independently): the route-tap interaction felt broken; proposed distinguishing Avoid (for the current trip) from Never use (persistent); suggested an icon to indicate good-quality roads; considered the “From here” button unnecessary; suggested grouping route preferences with the zoom, layers, and recenter controls; rated Saved Routes the easiest feature.
• Participant 3 (completed the road-avoidance task with help, remaining tasks independently): suggested a checkmark alongside the cross for the drag point; suggested the route line stay blue while dragging rather than switching to yellow; requested a separate, distinct edit mode; considered the Start button should be visible by default; did not engage with the onboarding pop-up describing route editing; rated Saved Routes the easiest feature.
• Participant 4 (completed the editing task with help, remaining tasks independently): did not engage with the onboarding pop-up describing route editing; requested onboarding to explain the features; rated Saved Routes the easiest and quickest feature.
• Participant 5 (completed independently): requested that voice commands accept free, natural phrasing rather than fixed syntax; did not notice the “pick on map” button; rated Saved Routes the easiest and quickest feature.
Incorporated After Iteration 2
• Voice commands to avoid or prefer roads during live navigation
• An onboarding message introducing the new features
• A road-quality icon shown alongside route time chips
• Voice-based confirmation for the reroute message
Note on unresolved feedback: Participant 3’s request for a separate, distinct edit mode directly conflicts with Participant 1’s Iteration 1 finding that drag-to-edit should not require one; the edit mode was removed after Iteration 1 and was not reintroduced. This is a genuine tension in the feedback, not a gap in the notes. The tick-mark/blue-line visual suggestions from Participant 3, and the free-form voice phrasing requested by Participant 5, were also not implemented in this pass.
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
TIMELINE — Round 3 (3 participants)
100% task completion across the full feature set, including voice and onboarding under first-time use
06
From Assumption to Evidence
The closing section separates evidence, production limits, next steps, and reflection so readers can scan the outcome quickly.
3
testing rounds
13
participants total
2
major design changes driven directly by testing evidence
—
As Maps becomes more automated, drivers require greater control, not less
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)
Reflection
• Testing can confirm a decision, not only expose flaws. The Avoid/Never use distinction was validated as built in Round 3; treating that as a real finding, not merely a formality, mattered as much as catching the drag-mode failure in Iteration 1.
• A technical constraint became a design input rather than an obstacle. OSRM’s rejection of hard road exclusions forced a soft-ranking approach to Avoid/Never use. The routing engine’s limits shaped the interaction model directly.
• A confirmation step is not automatically safe. The reroute pop-up in Iteration 2 satisfied the “ask before acting” principle but failed in practice, since it could not be read quickly enough while driving. The presence of a safeguard and the effectiveness of a safeguard are separate questions.
• Directing an AI-assisted build required translating ambiguous usability feedback into precise, testable instructions. “The drag interaction feels wrong” is not actionable; specifying the exact touch-event failure and the intended pointer behavior is. That translation was a design skill exercised throughout the project.
Closing statement: As Maps becomes more automated, drivers require greater control, not less. This project is built on that premise, and it is the specific tension the Emerging Experiences team is focused on solving.
MEDIA — closing shot, saved route list or final prototype screen