Context

Navigation products are exceptionally good at answering:

"What's the fastest way to get there?"

But real journeys aren't always about speed.

A driver navigating unfamiliar roads at night may care more about safety and predictability. Someone stuck in traffic may be frustrated or anxious. A passenger taking an unfamiliar cab route may want reassurance when the driver unexpectedly deviates from the expected path.

This project explored how an AI-native navigation experience could respond to those changing contextual needs rather than treating every journey as the same optimization problem.

The concept was designed around Google Maps, exploring how agentic AI could augment an existing navigation experience.

Project type: Self-initiated conceptual project
Scope: Single-feature implementation
Role: End-to-end Product Designer

I owned the problem definition, conceptual research, user segmentation, system architecture, UX flows, interaction design and mitigation strategies.

Problem:
Navigation optimizes the route. Users optimize the journey.

My initial problem framing was:

"I feel anxious. I don't want the fastest route - I want the safest and well-lit route."

Conventional navigation can prioritize factors such as time and distance, but this doesn't necessarily reflect the user's emotional state, context or perceived safety.

The opportunity was therefore not simply to create another route option.

It was to explore:

How might navigation adapt its recommendations to the user's changing context while keeping the user in control?

Research & User Definition:
Starting with the people, not the AI

I identified drivers and motorcycle/scooter riders as the primary user group for the concept.

The segment was selected because these users:

• Rely heavily on turn-by-turn navigation.

• Frequently encounter unpredictable traffic conditions.

• Can experience high cognitive and emotional load while travelling.

• Have recurring safety concerns, particularly during unfamiliar or nighttime journeys.

• Already depend on navigation products, creating an opportunity to augment an established behavior rather than introduce an entirely new one.

The project research estimated this primary group at approximately 60–70% of the target audience.

Research & Insights

Rather than treating navigation as one continuous task, I mapped the moments during a journey when context could meaningfully change the user's needs.

Moment 01: Before the ride

Users may need to:

• Confirm pickup location

• Check ETA

• Share their live location

• Assess whether they feel comfortable with the planned route

Moment 02: During traffic standstills

Long periods of congestion can introduce:

• Frustration

• Boredom

• Urgency

• Increased cognitive load

Moment 03: Unexpected route changes

A sudden deviation can trigger:

"Why are we going this way?"

This is particularly relevant when users are passengers in taxis/autos or travelling through unfamiliar areas.

Key insight

The opportunity wasn't to make navigation more personalized everywhere.

It was to identify specific moments where contextual adaptation could meaningfully improve the experience.

From Navigation to Context-Aware Navigation

The traditional navigation model is essentially:

Destination → Route → ETA → Directions

I explored an alternative:

Destination → Context → Route options → AI recommendation → User decision

The key product shift was:

From optimizing the route to optimizing the journey for the user's current context.

This could allow the system to consider factors beyond speed, such as:

• User-provided preferences

• Time of day

• Route conditions

• Journey context

• Perceived safety

• Interaction signals

The concept deliberately treats these as signals and hypotheses, rather than assuming the system can perfectly detect a user's emotional state.

Product Opportunity

What if navigation could understand why a user might reject the fastest route?

This led to the central concept:

Adaptive Navigation

An agentic AI layer could interpret contextual signals and dynamically modulate the navigation experience.

For example:

"You seem stressed. Take this route."

Instead of presenting the fastest route as the default answer, the system could surface a route better aligned with the user's current needs.

The important design constraint:

AI recommends. The user remains in control.

Design Principles

01 Context over convenience

Don't optimize for speed when the user's actual priority is different.

02 Explain, don't silently adapt

If AI changes the recommendation, users should understand why.

03 User control is non-negotiable

AI recommendations should remain overrideable.

04 Reduce cognitive load

Contextual intelligence should make navigation simpler, not add another layer of complexity.

05 Safety before novelty

An AI feature operating during a physical journey must be designed around failure scenarios, not just the happy path.

06 Personalization should earn trust

The system should progressively adapt based on useful signals rather than making opaque assumptions about the user.

Exploring the Interaction

I explored multiple approaches to determine how the adaptive recommendation should appear within the navigation experience.

Rather than immediately committing to one solution, I compared alternatives and evaluated them against UX trade-offs.

The evaluation criteria varied according to the project, with particular attention to:

• User comprehension

• Cognitive load

• Safety

• Control

• Contextual relevance

• Interaction effort

Design principle

Green light? Red flag? Check the UX trade-offs early.

This helped prevent the AI concept from becoming an elaborate technical solution without a clear user benefit.

The underlying exploration also raised important technical/product questions around:

• Which signals should be fed into each LLM?

• Where should those signals originate?

• How should prediction accuracy be strengthened?

• How many agents are actually necessary?

• Which tasks could be handled by simpler LLM components?

• Could smaller models run on-device to reduce cost?

• Where does conventional software/agency make more sense than an LLM?

These questions were identified as areas requiring further collaboration with AI/ML experts and developers.

Key Product Decisions

Decision 01 Don't optimize exclusively for speed

Alternative: Keep fastest route as the only optimization objective.

Why I moved away from it:
It doesn't account for situations where users prioritize safety, familiarity or reduced stress over arrival time.

Decision 02 Introduce contextual recommendations

Alternative: Add another static route preference.

Chosen direction:
Allow the system to dynamically consider contextual signals.

Why:
The user's priorities can change during the journey.

Decision 03 Make AI recommendations explainable

Alternative: Silently change the recommended route.

Chosen direction:

"You seem stressed. Take this route."

Why:
Unexpected AI behavior can reduce trust. The user should understand the recommendation rather than wonder why navigation changed.

Decision 04 Preserve user agency

Alternative: Automatically force the AI-selected route.

Chosen direction:
Recommendation + alternatives + user override.

Why:
Navigation is a high-consequence interaction. The AI should assist the decision, not remove it.

Decision 05 Avoid an unnecessarily complex multi-agent architecture

During exploration, I questioned whether every capability needed its own agent.

The project feedback highlighted that some tasks could potentially be accomplished using LLM components rather than introducing many independent agents.

Why this matters:
Agentic architecture should be driven by product requirements and system behavior - not by the novelty of using multiple agents.

Final Experience

The resulting concept turns navigation into a context-aware decision-support experience.

Instead of:

Fastest route: 32 min

the system could potentially surface:

Recommended route: 36 min
Better aligned with your current preferences

with the ability to understand:

Why?

What alternatives exist?

Do I want to follow it?

This creates a new interaction model:

Sense → Interpret → Recommend → Explain → Confirm

rather than:

Calculate → Display → Navigate

Trust, Safety & Failure States

Designing AI into navigation introduced a critical question:

What happens when the AI is wrong?

I therefore treated trust and mitigation as part of the product architecture rather than an afterthought.

Potential failure scenarios include:

Incorrect contextual inference

The system incorrectly assumes the user is stressed.

Mitigation: User override + explicit preferences.

Poor recommendation

The AI chooses a route that doesn't actually match the user's needs.

Mitigation: Alternative routes + transparent rationale.

Over-personalization

The system makes increasingly aggressive assumptions based on historical behavior.

Mitigation: User controls + explainability + bounded adaptation.

AI complexity

An unnecessarily large agent architecture increases cost and latency.

Mitigation: Evaluate which components genuinely require agents/LLMs and consider smaller or on-device models where appropriate.

These became important product questions rather than simply technical implementation details.

Validation Plan

This was a conceptual project, so I would not claim production validation or user-performance metrics.

Instead, I defined the next validation questions.

Hypothesis 01 - Contextual recommendations

Does adaptive routing increase perceived relevance compared with conventional route selection?

Hypothesis 02 - Trust

Do users understand why the AI recommended a particular route?

Hypothesis 03 - Control

Do users feel comfortable accepting, modifying or rejecting AI recommendations

Hypothesis 04 - Safety

Does the experience improve perceived safety without increasing cognitive load?

Hypothesis 05 - AI efficiency

Can contextual personalization be delivered without excessive model cost or latency?

The original project also identifies usability testing with target users and KPI definition as the next step toward iteration.

Success Metrics

Because this was not a live product, these are proposed validation metrics, not achieved results.