An AI travel companion that plans with you, helps in the moment, and turns a real trip into memories. It is built around one hard question: how do you make an AI people actually trust with their personal data?
Travel is personal. To be useful in the moment, Memory Map needs location, photos, and taste; to be trustworthy, it can't feel like surveillance. Three problems had to be solved together: the cold-start problem of learning a brand-new user with no history, giving in-the-moment help without endless prompting, and keeping the person visibly in control of everything the app captures.
The app learns your taste and drafts a flexible itinerary from taps and your own files, never a cold survey.
Context-aware, one-tap suggestions with a stated reason, plus an offline fallback when signal or data drops.
Real visited places become a scrapbook, journal, or shareable list, reviewed and editable before anything is shared.
I mapped the entire journey end to end, including what happens when location, photos, or signal aren't available, plus a persistent data-and-privacy control center that lets the user review, edit, or delete anything at any stage.
The hardest first-run moment is teaching the AI your taste before it has any history. A prompt box can ask "tell me places you've loved," but that dumps all the effort on the user. I designed the same moment three ways (same goal, same system, different interaction pattern) and evaluated the trade-offs.
| Interface Agent | Direct Manipulation | Mixed-Initiative Best fit | |
|---|---|---|---|
| Upfront user effort | Very low | High (up to 36 inputs) | Low (one input) |
| Trust required in the AI | High (reads personal files) | None guessed | Medium (reviewed per item) |
| Accuracy of first profile | Good, needs review | Excellent | Good, user-corrected |
| Works with no history | No (needs files to read) | Yes | Yes |
| Transparent while running | Low (works in background) | High | High (every step visible) |
Why mixed-initiative won: it mirrors the principle the rest of the app already runs on: the app senses and drafts, the user confirms. That is the same shape as the live "did you go here?" check-in. It avoids the agent quietly reading files with no checkpoint, and avoids 36 inputs before the app says anything useful.
I prototyped the same core flow at two fidelities: a high-fidelity build (clickable, real-feeling) and a Wizard-of-Oz simulation (hand-labeled cards revealed live, no logic behind them). Same task, same debrief questions, so I could compare what each method surfaced.
The insight: higher fidelity didn't mask weak function. It raised expectations. Testers expected personalization and transparency, and got specific when those were missing. Three implications carried into the final design:
Capture new-user preferences before the first recommendation, so cold-start doesn't feel cold.
A short rationale next to each pick, like "rainy weather → indoor pick," plus a confidence level.
Spell out what each permission is for, with a persistent data-use bar on every screen.
The goal isn't to make people trust the app as much as possible. It's to match their confidence to what the system can actually deliver. The final design tempers over-trust and counters the under-trust the Wizard-of-Oz test exposed, through honest onboarding, a "Why this pick?" with a confidence level, and a getting-to-know-you agent that shows its work.
I designed one moment, "get a coffee nearby and remember the visit," three ways, each earning trust through a different mechanism. Keeping all three live lets the recommendation be revisited as trust matures.
Max control. Trust via authorship, which answers algorithm aversion, at the cost of effort.
It's raining and you're near the hotel. Want a coffee stop?
Looks like you spent 42 min at Café A. Add it to your timeline?
App proposes, human decides. Trust via transparent reasoning + a reversible confirm-loop.
Acts first, then logs a "why" with one-tap undo. Trust calibrated after the fact.
Recommendation → Variant B. It preserves the passive-capture value that makes the product worth building, while keeping the user in control at the moment of decision, and it reuses the confirm-loop already at the heart of the design. Variant A sacrifices the core benefit; Variant C asks for trust that testing showed users aren't ready to give.
Because the app captured places the honest way, passively and with confirmation, so the "Remember" phase writes itself. Visited places over 15 minutes become a reviewable timeline the user can turn into a scrapbook, journal, or shareable list, fixing anything before it's shared.
Low fidelity tested the idea; high fidelity tested expectations. Choosing fidelity deliberately changed what I learned, and when.
The strongest move wasn't more polish or more automation. It was making the system legible: a "why," a confidence level, and a visible data-use bar.
Sense-and-confirm shows up in onboarding, live suggestions, and capture. One consistent AI pattern did more for trust than any single screen.
Test the mixed-initiative onboarding with users who have no travel files, and instrument the confirm-loop to see how often people correct the AI, a real signal of calibrated trust.