Product design

Two products,
one question

How I designed two versions of (re)Route –each a different answer to the same problem, each teaching me something about what it means to build with AI.

← V1.0 –The smarter map V2.0 –Side quests →
What would walking be like, if it wasn't just "optimised" time?

Navigation apps treat journeys as dead time between A and B. But the people I interviewed didn't want faster routes –they wanted a reason to look up. This question drove both versions of (re)Route, and the pivot between them.

1.0
The smarter map · rerouted.vercel.app

A map that understands intent

My first instinct was to build a better Google Maps. Instead of just "fastest route," what if the app understood why you were walking?

UX decision: Three entry points, not one search bar

Google Maps has one paradigm: search → route → follow. User research showed three distinct walking intentions that needed different interfaces:

Design logic

Three entry points reduce decision paralysis. Instead of an empty search bar that triggers the Google Maps mental model, users self-select their intention level. This guides both the UI they see and the AI pipeline that runs.

AI decision: LLM as orchestrator, not chatbot

The AI doesn't talk to the user. It classifies their query into one of 6 action types and returns structured parameters that drive a deterministic UI pipeline. One GPT-4o-mini call decides the action; specialised executors handle the rest.

6 action types

ActionTrigger
generate_walk"calm 30 min walk," "get lost"
dest_route"walk to Sagrada Familia"
search_places"best vermut," "laptop-friendly cafe"
plan_experience"artsy date night," "vermut trail"
themed_walk"Gaudi walk," "gothic quarter"
explore_area"explore Gracia," "waterfront"

Tiered search strategy

The orchestrator also classifies which search pipeline to use:

  • Standard –Google Places keyword search. For "tapas near me."
  • Reasoning –GPT-4o generates 5–6 candidates by name + reasoning. For "artsy date spot."
  • Web-grounded –GPT-4o + web search tool. For "underground bars" or "new cafes."

All reasoning/web candidates pass through a hallucination filter: cross-checked against Google Places. If the place doesn't exist, it's dropped.

Data decision: Mood-weighted street scoring

119,000 street segments scored across 5 dimensions (noise, greenery, cleanliness, cultural richness, liveliness) from Barcelona Open Data. Each mood applies different weights to generate distinct route alternatives from the same origin/destination.

119k
Street segments scored
372
Curated POIs (hand-verified)
5
Scoring dimensions
6
Mood profiles
What made it different from Google Maps

Barcelona Open Data Street quality scoring that Google doesn't have.

372 synthetic POIs Places that don't exist in Google Places.

User-centred pipelines Different UX flows per query type.

UI experiment: Where AI output surfaces

The key UI challenge: AI does a lot of work behind the scenes, but how does that intelligence appear to the user? Every AI output needed a visual home that felt earned, not generic.

Design principle

AI output should answer the specific question asked, not display generic data. The verification tag tells you why this place fits your query. The route description tells you what the streets feel like. The proximity toast tells you what's next to you right now. Every AI surface is scoped to a moment of decision.

What 1.0 revealed

"4 out of 5 users still used it exactly like Google Maps."
User testing insight

Places search, keyword-based, no nuance. The tool wasn't the problem. The paradigm was. Even people who said they wanted to explore more defaulted to "tapas near me."

Diary study insight

"For me, that's all the problem of motivation to explore rather than knowing where to go once you are in the mood to explore."

* People don't need more directions. They need more inspiration.

The pivot

From routes to quests

The search → route → follow loop is single-use and screen-heavy. Quests create a repeatable gameplay loop with progression, and they give people the reason to go outside that the map never could.

2.0
Side quests · the city as a game

A game master, not a map

V1 built a smarter map. V2 asks: what if the app didn't show you a map at all? What if it gave you a reason to walk –and a camera to prove you did?

UX decision: The core loop

1
Accept
Choose a quest from the deck. AI generates them from weather, time, location, events, and your taste profile.
2
Walk
Navigate by compass, not polyline. A direction, not a path. Get lost or and find your way whenever.
3
Snap
Photograph what the quest asks you to notice. The camera is the interaction, not the screen.
4
Verify
AI judges your snap against the quest's vibe. Strict enough to be a game. Loose enough to reward noticing.

Design logic

Every step reduces screen time. Accept is a swipe. Walk is compass-only. Snap uses the camera (you're looking at the world, not the phone). Verify is instant feedback. The phone becomes a camera, not a GPS.

Product decision: Three quest types

Each type tests a different kind of presence:

VISIT
GPS-verified proximity
Navigate to specific locations. The system auto-detects when you arrive within range. No snap, just being there counts.
WANDER
AI-verified snaps
Take photos matching a theme while walking freely. AI vision judges if your snap captures the quest's intention.
COLLECT
AI-verified + count target
With a target count and long-term progression. "Photograph 100 cats" becomes a persistent collection that unlocks badges over weeks.

AI decision: Five quest generation paths

Quests should never feel stale. Five sources with different approaches:

Live
Real-time triggers
Sunset windows, market hours, weather events. Gemini + web search + solar calculations. Ephemeral –disappears when the moment passes.
Daily
Community quest
Same quest for all users today. Creates shared experience and participation tracking. Rotates from curated pool filtered by weather and time.
For You
Taste profile
Per-user daily quest generated by cron job. Uses your taste profile (learned from snaps) to generate quests shaped by what you notice.
Library
Curated database
Hand-written Barcelona quests stored in Supabase. Quality-scored. Zero API cost. The reliable fallback that never hallucinates.
Chat
User-requested
"Give me a quest about street art." Gemini picks from library or generates new. The only path where the user explicitly asks for AI output.
Why five paths matter

Quest fatigue is the #1 threat. If generation quality drops or quests repeat, the magic dies. Five sources with different refresh rates (real-time / daily / personalised / stable / on-demand) ensure there's always something genuinely new. The library is the floor; live events are the ceiling.

UX decision: Compass replaces polyline

v1.0 Polyline
  • Eyes on screen
  • Follow the blue line
  • Turn-by-turn
  • Replicates Google Maps
v2.0 Compass
  • Glance and go
  • A direction, not a path
  • You choose the route
  • Feels like exploring
North star metric = Snap-to-navigation ratio

High snaps + few map interactions = the phone is a camera, not a GPS.

AI decision: SNAP as verification ritual

SNAP is the moment where AI and human presence meet. The user photographs something; the AI judges whether it matches the quest's intention. The calibration is critical:

VISIT
GPS proximity
No photo needed
System checks: are you within range of the location? Binary pass/fail. Locations logged and checked off the compass map.
WANDER
AI vision
"Does this capture the vibe?"
AI matches photo against quest intention. Strict enough to prevent gaming. Loose enough to reward genuine noticing.
COLLECT
AI vision + count
"Is this a [thing]?"
More generous: if you're on your 47th cat photo, the AI trusts you. Sustained collection over per-snap perfection.

AI decision: "Attention intelligence"

Your snaps teach the app what you notice. Over time, it reflects your attention back as quests designed for the way you see the city.

You snap photos
Every snap carries signal: what you pointed the camera at, when, where, for which quest
AI builds taste profile
Gemini analyses activity patterns into natural-language taste notes: "loves quiet courtyards," "drawn to colour on grey walls"
Taste shapes future quests
FOR YOU quests and CHAT responses use the profile. The more you walk, the more personal it gets.
Taste travels with you
Unlock a new city → your taste profile generates quests tailored to you in a place you've never been. This is the data moat.
Product strategy

The taste profile creates switching cost that no competitor has. Google has POI data. (re)Route knows what you notice. The profile is built for free in your home city –it becomes the reason tourists pay for city unlocks.

Gamification: Badges as motivation, not pressure

24
Achievement badges
Walking stats: streaks, time of day, distance
15
Collection badges
Snap themes: cats, doors, pigeons, murals
Design logic

You're collecting evidence of your own attention. The game is between you and the city –progress without pressure.

Badges screen 1
Auto-verified
Badges screen 2
No leaderboard
Badges screen 3
No competition

UI experiment: Where AI output surfaces in 2.0

In 2.0, AI is more present but more hidden. Every AI output is wrapped in game language and pixel art, so it never feels like "talking to an AI."

V1.0 vs V2.0: AI visibility

In 1.0, AI output appeared as data annotations layered on top of places and routes. In 2.0, AI output appears as game content wrapped in a visual identity.

But not everything that feels smart is AI. The responsive landscape, the countdown timers, Re's thought bubbles – these are deterministic design choices (weather APIs, cron jobs, conditional rendering) that create an ambient sense of awareness. They make the actual AI outputs land in a context that already feels alive.

What changed between versions and why

Decision 1.0 2.0 Why it changed
NavigationRoute polylines (ORS)Compass ring onlyPolylines replicate Google Maps. The compass forces you to navigate by looking at the city, not the screen.
Core loopSearch → route → followQuest → walk → snap → earnRoutes are single-use. Quests create a repeatable gameplay loop with progression.
AI roleGPT-4o-mini classifies intent, ORS generates pathGemini generates quests, validates snaps, builds taste profileShifted from routing intelligence to creative intelligence. AI writes the narrative and judges photos.
IdentityAnonymous, statelessDevice UUID, persistentQuest completion, badges, and taste memory require identity that persists across sessions.
CameraNot implementedFull snap system + AI validationSnaps turn walking into active noticing. The camera reframes exploration as attention.
DesignTailwind + monospace brutalismPixel art brutalism (Silkscreen + Space Mono)No rounded corners, hard shadows, pixel art landscape. The app should feel like a game, not a tool.
GamificationNone39 badges, streaks, taste profileExploration needs motivation loops. Badges create engagement without efficiency pressure.
ContentGoogle Places + curated POIsAI-generated quests + curated libraryPlaces are finite. Quests are infinite. AI generates fresh missions from the same city data.
SharingSave routes locallyPublic snap map + shareable collectionsUser snaps become the discovery layer for the next user. The product markets itself through content.

Design principles for building with AI

Lessons from designing two AI products – what worked, what didn't, and what I'd do again.

01
AI should be invisible
V1 leveraged AI as a orchestrator in an agentic flow. V2 wraps it in a smart gamified role. No prompts, no spinners. Just a better experience.
02
Design the output, not the input
V1 let users type freely – powerful but unpredictable. V2 designs the output instead: quest cards with specific verbs and targets.
03
Give AI a role, not a feature
V1 used AI as a smart assistant. V2 gives it a role: A game master who writes quests, judges photos, learns taste.
04
Hallucinations as creativity
In V1, hallucination meant fake places. In V2, it becomes the creative engine – AI invents quests within constraints.