EchoMap
A private location-based memory journal that helps people connect personal stories with the places where they happened.
- Role
- Sole designer — concept, product thinking, flows, UI, prototype
- Discipline
- UX design · UI design · Product thinking
- Platform
- Mobile app
- Tools
- Figma, Auto Layout, Interactive prototyping
A design concept, developed end to end. No user research or usability testing has been conducted.
projects/echomap/cover.pngOverview
Context
A photo of a place is not the same as the memory of it. The camera roll keeps the image and loses everything around it — who was there, what it felt like, why it mattered. Meanwhile the platforms designed for memories are built for audiences, not for the person remembering.
Problem
There is no comfortable place to keep something personal that is tied to a location. Journals are not spatial. Social apps are not private. Photo libraries are chronological, and a life is not.
Objective
Design a private space where a memory lives at the place it happened, and comes back on its own terms.
What I did
- Defined the product concept and who it is for
- Designed the capture, storage, and rediscovery flows
- Worked through the privacy and consent model, including suppression controls
- Built the interface system and interactive prototype
Who it is for
People roughly 18–35 who want somewhere private to keep what a place meant.
The audience is people who already document their lives, but are increasingly uncomfortable doing it in public. They want the act of keeping a memory without the performance of publishing one — no audience, no metrics, no algorithm deciding what resurfaces.
That framing rules out a great deal by design. There is no feed, no following, no likes, and no sharing as a primary action. Every one of those would quietly turn a private journal into a small social network, and the product would stop being the thing it set out to be.
The challenge
Rediscovery is the feature, and also the risk.
The whole idea rests on memories coming back to you when you are near the place they belong to. That is what makes it more than a journal with coordinates attached.
It is also the part that can hurt. Not every memory is one you want surfaced unprompted — a place can be tied to a person you have lost, a relationship that ended, a period you would rather not walk back into. An app that cheerfully announces a memory is near you outside the wrong building has done real harm with a feature it thought was delightful.
So the central design problem was not how to make rediscovery work. It was how to make rediscovery something the user stays in control of, without making them configure a settings panel to feel safe.
The principles it is built on
Product positions, arrived at by reasoning through the failure cases.
- 01
Private by default, with no path to public
Memories are private at rest and there is no sharing flow to accidentally fall into. Privacy is the architecture, not a setting to switch on.
- 02
Capture must be nearly free
Place and date are detected automatically. If keeping a memory takes effort, it happens only on remarkable days — and the ordinary ones are the ones worth having later.
- 03
Rediscovery is offered, never imposed
A proximity notification is an invitation. It can be dismissed, muted for a place, or turned off entirely, and the app does not ask again.
- 04
The user can close a door
Any memory or location can be suppressed from resurfacing without being deleted. Keeping something and not wanting to meet it today are different needs.
- 05
Some things need a locked drawer
A separate private space holds sensitive entries, kept out of the main map and out of rediscovery altogether.
How it works
Capture, keep, and — only if wanted — return.
- 01
Arrive
The place and date are detected automatically, so a memory starts with its context already filled in.
- 02
Capture
Write it, add photos, record audio or video, or capture live in the moment.
- 03
Keep
The entry is stored privately against its location. Sensitive entries can go to the private space instead.
- 04
Return
Passing nearby later, an optional notification offers what is there — without revealing it in the notification itself.
- 05
Control
Open it, dismiss it, mute this place, or suppress the memory from resurfacing. All of it reversible.
Key design decisions
The ones that decide whether this product is safe to use.
Notifications reveal proximity, not content
- Evidence
- A notification is read on a lock screen, in public, by whoever is looking. Putting the memory in the preview leaks it to the room.
- Alternative considered
- Show a snippet or photo thumbnail to make the notification more enticing.
- Decision
- The notification says only that something is nearby. The content stays behind the app.
- Trade-off
- A less compelling notification, and probably a lower open rate. The right call for a private journal.
Suppression is separate from deletion
- Evidence
- Forcing a choice between meeting a painful memory and destroying it is a cruel piece of interaction design. Both options are wrong.
- Alternative considered
- Offer only delete, or only mute-everything.
- Decision
- Memories and places can be suppressed from rediscovery while remaining intact and reachable deliberately.
- Trade-off
- More states to design and explain, in exchange for the app never being the reason someone loses something.
A private space rather than per-entry locks
- Evidence
- Sensitive entries are sensitive as a category. Locking them one by one leaves the map itself telling the story of where you have been.
- Alternative considered
- A lock toggle on each individual memory.
- Decision
- A distinct private space, excluded from the main map and from all rediscovery.
- Trade-off
- A second place to look for things, mitigated by making the boundary explicit and easy to move entries across.
No feed, no followers, no sharing
- Evidence
- Every social affordance changes what people are willing to write. The moment an audience is conceivable, entries become performances.
- Alternative considered
- Optional sharing, or a private-by-default feed.
- Decision
- The product has no social layer at all.
- Trade-off
- Gives up the growth that sharing brings. Keeps the only property that makes the product worth using.
The experience
Map, memory, capture, and the controls that keep it comfortable.
projects/echomap/map.pngprojects/echomap/memory-entry.pngprojects/echomap/capture.pngprojects/echomap/notification-controls.pngVisual system
Warm and quiet — a journal, not a dashboard.
Typography
- A warmer type pairing than a utility app would use, with room for longer writing
- Generous line height and a constrained measure, because entries are meant to be read
- Dates and places set small and consistent, so they frame the entry without leading it
Colour
- A soft, low-contrast base that stays comfortable when reading at night
- Accent reserved for capture and for the current location on the map
- No alarm colours anywhere in the rediscovery flow — nothing here is urgent
Components
- Memory card: place, date, and an excerpt, with media indicated rather than previewed
- Map pin: single, clustered, and private-space variants
- Capture sheet: one surface covering text, photo, audio, and live capture
- Control sheet: the dismiss, mute, and suppress actions, described in plain language
Interaction states
- Every suppression action is reversible, and says so at the point of use
- The private space is visually distinct so its boundary is never in doubt
- Empty states explain what the app will do with a memory before asking for one
Design concept
What has and has not been validated
EchoMap is a design concept. It has not been built or released.
No interviews, surveys, diary studies, or usability tests have been run on it. The audience described here is a design assumption, not a research finding, and the principles are reasoned positions rather than validated conclusions.
The part I would most want to test is the language around suppression and the private space. Those controls only work if people understand them under emotional pressure — and that is exactly the kind of comprehension that cannot be assumed from the designer’s chair.
Outcome and reflection
EchoMap holds together as a coherent product argument: memory tied to place, kept private, returning only when it is welcome.
The most useful thing this project taught me is that consent is an interface problem. The features that make a product feel thoughtful are usually the ones that let someone say not now without penalty — and those are easy to leave out, because nobody demos them.
It also taught me to be suspicious of delight as a goal. The proximity notification is the most charming idea in the product and the one most likely to cause harm, and designing it well meant making it quieter than my first instinct wanted.
Contact
Have a product idea worth shaping?
I’m open to UI/UX and product design roles, and to freelance design and frontend projects. Tell me what you’re working on.