Google Maps Recall - Redesigning how Google Maps remembers places for you, so capturing a place costs one tap, and finding it again doesn’t require remembering what you named it.
- Role
- Product Design (solo, end-to-end)
- Duration
- 1 month
- Tools
- Figma, React, Tailwind, Claude, Notion
The problem
Saving a place is one tap. Organizing it isn't, and that mismatch is the whole problem.
The moment someone decides to remember a place almost never happens at a desk. It's mid-walk, mid-conversation, with zero patience for a decision. The only cost people will actually pay is one tap.
“I’ll remember this place. I never do.”
Under-capture. The moment passes, nothing gets saved.
“I saved it. No idea which one it was.”
Over-capture. It’s saved, but lost in 300 unlabeled pins.
None of these are edge cases in the dismissive sense. They’re the actual product, just the parts that don’t show up in a three-screen demo.
I looked at how Google Maps, Yelp, and Apple Maps each handle saving and organizing places today. All three, independently, arrived at the same shape of solution: manual folders the user has to name and maintain at the moment of saving. That's fine for planned use: building a vacation itinerary, calmly, at a desk. It's a mismatch for the spontaneous, high-frequency moments where most real saving actually happens.
Research & Competitive Landscape
Every major player has converged on the same answer, and the same gap.
Google shipped a competing idea while I was mid-project.
The overlap. In March 2026, Google rolled out "Ask Maps," a Gemini-powered conversational search accessible right next to the search bar. It directly overlapped with a feature I was already designing. My first reaction was that it had made half of Feature 2 redundant.
What changed my read. Ask Maps personalizes results using your saved places as a ranking signal, but it never treats your saved corpus as a distinct, primary layer checked first. Everything comes back blended into one answer. It's a personalized discovery engine, not a memory-retrieval engine.
What I did. That reframed the feature instead of killing it. The conversational search bar stopped being the differentiator; Google made that table stakes. I rebuilt Feature 2's UI to match Ask Maps' shipped pattern, while keeping the memory-first structure as the one thing Google's own version doesn't do.
Opportunity & Persona
One user carries all four gaps at once.
Research & Competitive Landscape showed what each competitor does today. Here's the synthesis: four concrete gaps, and what Recall does differently for each one.
#
Competitors
Recall
1
Named list required at save-time
Zero-decision save, AI tags applied automatically
2
One place, one list only
Concurrent tags: vibe, cuisine, and geography at once
3
Notes attached, but not reliably searchable
Notes become structured memory tied to the tags
4
Retrieval means browsing lists
Dual-layer search checks saved places first, shown as an explicit distinction
Maya, 29
Product & Brand Marketing Manager
Brooklyn, NY
Goal
Be the friend who always knows a place, without having to remember or search manually.
Frustration
Naming a list in the moment feels like admin work, so she often just doesn't save at all.
Trigger moment:
Mid-walk, mid-conversation, she passes a place that looks great. She has three seconds of attention to give it, not thirty.
"When I discover a place I might want to return to, I want to capture it with zero friction and trust I can find it again by vibe, occasion, or area."
Some of what's actually new
AI Organized Tag Group. Three concurrent tag slots applied automatically at save, never a form waiting to be filled in.
Custom Tag Picker. A second, open-ended tagging layer next to the three fixed ones: name any category, and it gets a consistent color the moment it exists, no admin screen required.
Memory Card. The saved-tab grid tile: photo, tags, and a note flag in one card. The multi-select filter bar above it is built only from what's actually saved, so any combination you pick still returns something.
Match Reason Card. Saved-or-discovery badge plus a "why" tied to the actual parsed query, never a generic recommendation. The All / Your pins / Discovery tabs above it filter that same result set three ways, not two separate searches to reconcile.
A
Category label
Icon
Color
Value text
Everything, every time.
B
Category label
Icon
Color
Value text
Lighter, but too flat to scan.
Never built, cut before implementation.
C
Shipped
1×
Category label
Icon
Color
Value text
Chip stays whole. Label moves.
Chose C. It keeps the one signal (icon) that actually earns its place for fast, non-color-dependent scanning, and removes the one that was purely repetition.
The ‘teach once’ logic assumes the user witnessed that first save. A handful of pre-seeded places in the demo data skip straight to the label-less version, a known, scoped-out edge case, not an oversight.
What the evidence shows
Proven. Hospitality businesses clearly do pay for this category of insight. SevenRooms, a widely adopted restaurant CRM, builds guest profiles auto-tagged by occasion, fed by reservation and point-of-sale data, and restaurants use it directly for service and marketing decisions.
Unproven. Recall’s version would come from a different, unproven source: anonymous tags people applied to a place in their own private saved lists. Three open questions nobody has answered yet:
Would the product ever expose that private data back to businesses, even aggregated and anonymized?
Would a typical small business have enough saves for the signal to mean anything, versus noise from a handful of users?
Would an owner trust a signal from strangers’ private habits over first-party data they collected themselves?
What I did instead. I wrote a validation plan instead of a dashboard: short interviews with 3 to 5 independent business owners, covering how they currently learn why customers chose them, whether they’ve used tools like SevenRooms, and their honest reaction to the idea itself. Depending on what that surfaces, this either becomes 2 to 3 real screens, or stays exactly what it is now: a documented, honest example of testing an idea before forcing it into the product.
"I chose not to design screens for a hypothesis I hadn’t validated yet. The interview plan is documented. The dashboard isn’t built, and that’s the point."
Empty state, not just absence of data
The Saved tab doesn’t default to a blank screen. It explains what the feature does and how to start, since a first-time empty state is onboarding, not just an absence of data.
Every dead end offers a next step
No silent empty screen. An explicit message names the gap and offers to broaden the search, so a dead end always comes with a next action.
State lives in the app, not the screen
Every keystroke writes straight to shared state, not local screen state. Close the sheet mid-sentence, come back later, it’s still there, exactly as you left it.
None of these are edge cases in the dismissive sense. They’re the actual product, just the parts that don’t show up in a three-screen demo.
What I’d do with three more weeks.
This was a solo project, start to finish: research, information architecture, interaction and visual design, and a coded, working prototype rather than static screens. Three things I’d want more time for:
Actually run the validation interviews scoped out in Scope Decision, instead of just documenting the plan.
Usability-test the two-stage Place Sheet (peek, then scroll to expand) with real users. It’s the interaction I iterated on the most without ever watching someone else use it.
Replace the mocked AI tagging with a real model call, and see how often the three-tag structure actually holds up against messier, real-world places.
Designed and built solo in Figma, React, Tailwind, Notion, and Framer.
