Mental Connect

An AI-driven clinical product, where getting trust wrong has a real cost

Overseas Medical Centers runs a two-sided platform for catching and treating depression early. An algorithm reads patients' medical records and flags early symptoms; flagged patients are offered the app. On the other side, doctors get a dashboard and can build their own courses and assign them to specific patients.

I designed the patient side — mobile and desktop: the course, the tests, and the trackers for sleep, anxiety and mood. I was the sole designer and the researcher on it, and I ran a series of interviews with both patients and doctors before designing anything. The detection algorithm and the doctor-facing side were built by others.

The design question underneath the whole product: how does the output of an automated system reach a vulnerable person — and in what form will they accept it?

The product is live and in use in the clinic today.

Medical records, a clinic that knows you, and three parties to align

• Sensitive data. The product is tied to patients' medical records — the most personal data there is.
• Three sides with different needs. Patients needed safety and dignity, doctors needed a manageable workload, the clinic needed a product that fits its care process.
• A fixed request. The therapists came with a clear brief: a structured course inside the app.

I'd designed a course like that before, for a prenatal mental-health app, so I knew what the format does well — and where it stops helping. I treated the brief as a hypothesis to test with patients, not as the design.

Trust in AI tracked perceived distance, not intelligence

Two things from the interviews reset how I thought about the product.

The first was grounding: depression showed up across people of very different ages and lives — not a "type." Whatever I designed couldn't assume a typical patient.

The second was the real insight, and it was counter-intuitive. People did not want an AI standing in for their therapist — but not because they thought the AI was dumb. It was trust, and specifically perceived distance. Inside a named company's app, an AI felt unsafe: behind it were specific people who could, in a patient's imagination, trace them — a specific vulnerable person with a specific record. Something like ChatGPT felt safer by comparison — not because it's more private, but because it feels anonymous and far away.

So trust didn't track intelligence, and it didn't even track actual privacy. It tracked perceived distance and anonymity. In a clinical app tied to your records, that has a hard consequence: the anchor of trust has to be a human — the doctor — with the automated system working behind them, not in front of them.

Patients accepted being watched over by a doctor, because that's a person whose role it is. They would not have accepted being watched over by a company's AI.

A human in the loop at the moments that matter

Two decisions, both aimed straight at the insight.

A doctor's feedback on every automated result

When a patient completes a test, they don't just get an automated score — they can receive a personal note from their own doctor, right there in the app. At the exact moment another product would hand you an algorithm's verdict, this one hands you a sign that a specific, living doctor is paying attention. It's a human-in-the-loop pattern built into the patient's side, instead of leaving the doctor hidden behind their own dashboard.

A tone of voice built from the "ideal therapist"

In the interviews I asked patients and doctors to describe the character of an ideal therapist — and built the product's tone of voice from that, rather than a default friendly wellness voice. If trust rests on a trusted human, the system has to sound like one. The voice was designed from what people said they trust.

Alongside these, the patient side carried the working parts of the care — the assigned course, the tests, and the sleep / anxiety / mood trackers — on mobile and desktop. I built a reusable component library and handed it to the development team, who implemented the product in React.

Design the human's place before the machine's

What I took from this into every AI product since: users don't calibrate trust by how capable a system is. They calibrate it by who stands behind it and how close that feels. So the design work isn't hiding the automation or showing it off — it's deciding where a human must stay visible, and making that moment explicit.

Live in the clinic

The product is live and in use in the clinic. I don't have clean success metrics from real-world use, so I won't invent any. What I can stand behind: a patient-facing product on two platforms, researched and designed end to end by one person, in a high-stakes context — and a central decision about the role of AI that came straight out of listening to patients and made it into the shipped product.

Patients in the room even earlier

I'd bring patients in before the course structure was agreed with the therapists, not after — the interviews changed the product's voice and its key moments; started sooner, they could have shaped its skeleton too. And I'd run the "human in the loop" principle through the whole experience, not just two touch-points — including how the app first explains to a patient that an algorithm flagged them, and who sees their data.