A privacy policy describes obligations, but it is rarely where a person decides whether a product feels trustworthy. That judgment happens while choosing a photo, granting a permission, sharing a profile, receiving a message, or trying to delete an account.
For products like Found and Epilogue, personal information is not incidental. Identity, preferences, interests, writing, and conversations are part of the experience. Privacy therefore has to shape the interface and data model from the beginning rather than arrive as legal text at the end.
Ask at the moment of understanding
A permission request is meaningful only when a person understands what action requires it. Asking for notifications, location, camera, and contacts during the first launch may increase grant rates, but it gives no concrete reason to say yes. Contextual requests connect the permission to an immediate benefit.
The explanation should remain accurate if the person declines. If a feature can work with manual input or a limited alternative, show that route. Consent becomes coercive when the interface implies that a broad permission is essential even though the product can continue without it.
Defaults communicate the real position
A company may describe privacy as a priority while setting every profile field to public and every notification to enabled. Most people use defaults, so the initial state carries more weight than the promise. Sensitive fields should begin conservatively, and public visibility should be a deliberate choice.
Optional information must genuinely be optional. Labels such as Prefer not to say are useful only when the system does not later penalize the choice through lower discovery, repeated prompts, or an incomplete-profile warning that never disappears.
Show where information travels
People think in audiences, not database collections. They want to know whether a detail is visible to everyone, potential connections, accepted connections, collaborators, or only themselves. The interface should describe those audiences wherever information is created or changed.
- Name the audience beside sensitive fields
- Preview a profile as another person will see it
- Explain what a shared link reveals before it is copied
- Separate public activity from private conversation
- Keep blocked users outside every visibility path
Make safety actions complete and reversible where appropriate
Hide, mute, unmatch, block, and report solve different problems. Combining them into one vague action makes consequences hard to predict. Each control should state what changes, whether the other person is notified, and how the decision can be managed later.
Blocking needs special care because it is a boundary, not a preference. It should apply across cached content, deep links, search, chat, and notifications. Unblocking can be reversible, but it should not silently restore an old relationship or reopen communication.
Deletion must mean something
Account deletion should be findable, understandable, and confirmed without becoming an obstacle course. The product should explain what disappears immediately, what must be retained for legal or safety reasons, and how long the process may take. Logging out is not deletion, and deactivating visibility is not the same as erasing an account.
The strongest privacy experiences reduce surprise. They make collection proportional, audiences legible, defaults respectful, and exits real. Legal compliance remains essential, but trust is built one interaction at a time.