← All projects

Mektoube / Trust & safety · Interaction design

Protect a face without hiding a person.

I designed privacy controls for sensitive moments in a dating app: appearing in discovery, becoming recognisable and moving from messages to voice.

My role
Head of Product & Product Designer
Collaborators
CEO · Customer Support
Engineering & QA
Scope & experience period
Research · Privacy flows · UX writing · QA
Mektoube, 2023–2026
The case in 30 secondsGo to decisions ↓

The problem

Full blur hid social context; moving to voice could remove control too abruptly.

The decision

Protect the face rather than the entire image, and make calls permission-based.

My contribution

Privacy flows, explicit refusal rules, interface states, UX writing and QA.

Mektoube — Protect a face without hiding a person.
01 / Context

People wanted to participate, without becoming visible too soon.

A photo was mandatory on Mektoube. Full-photo blur protected identity, but also removed posture, setting and style: the context that makes a profile feel like a person. Moving from messages to a call created a second threshold, where control could disappear too quickly.

The point

The goal was progressive trust: let people decide when they become more visible and reachable.

02 / Research & constraints

Privacy had to work within real product rules.

I combined behavioural dashboards, user conversations, surveys and usability tests. Photos had to remain mandatory. Existing full-blur settings could not change without the user’s choice. Calls could not reveal a personal number, and declining had to have a consequence in the product.

03 / Face blur

Keep social context. Protect identity.

For new uploads, I designed two clear options: a visible photo or a face-blurred photo. Masking the face preserved the rest of the image. Existing users kept full blur until they changed it themselves. I specified detection, preview, upload, editing and rendering behaviour across the app.

Original comparison: full-image blur and face-only blur. The visual context remains available while the face is masked.
04 / Audio calls

A call starts with permission, not an interruption.

A user sends a call request. The recipient can accept once, allow future calls or decline. Declining pauses new requests for seven days. After a missed call, the recipient can call back immediately while the original caller has to wait. The call stays inside the app.

A refusal changes the system

The seven-day pause prevents an immediate sequence of repeated requests.

A missed call is not a refusal

The person who missed it can choose to call back without the same waiting rule.

Request and response states from the original project. Consent is part of the interaction, not a setting hidden elsewhere.
05 / Delivery & learning

Trust lives in the states people actually encounter.

I owned the work from research through flows, UI, UX writing, behaviour documentation and QA. The key delivery question stayed the same across every state: does the person understand what they control, what the other person can do and what happens next?

Evidence & scope

No feature-specific uplift is claimed here. The case demonstrates product rules, interaction detail and delivery ownership.

Next project / Yassir · SEFAR

Build a shared language while products keep moving. ↗

A role, a team, a product to build

Let’s make something useful.

Tell me about your product, the decisions ahead and where you need design to make a difference.

Get in touch ↗