Designing AI-powered stress detection for the worst moment — when a user is in active distress and can barely open an app. The AI wasn't the hard part. Trust was.
"If a user is in distress and they have to think to use this, we've already failed. The hard design problem isn't the AI. It's trust under stress."
ZenSense was an AI-powered iOS wellness app that used biometric signals to detect stress before users consciously recognised it — and surface interventions at the moment they were needed. The engineering team had the model working. The brief was: design the user experience around it.
But the research revealed an entirely different problem. Users didn't engage with the AI — not because the predictions were wrong, but because they didn't trust them. More precisely: they didn't understand them. An AI intervention that arrives uninvited, with no legible reasoning, at a moment of vulnerability, is not a wellness feature. It's an intrusion.
The design challenge shifted from "how do we surface AI insights" to "how do we design trust for an AI operating in someone's worst moment." That reframe changed everything — the interaction model, the language, the pacing, and ultimately the outcomes.
Three patterns from beta made the problem concrete.
In beta testing, nearly three quarters of users dismissed the first AI intervention without engaging — within seconds. Not because they were fine. Because the alert arrived without context or legibility.
When asked why they thought the app had flagged that moment, 3 out of 4 users said they had no idea. "It just showed up." No explanation = no trust = no engagement at the critical moment.
Users who dismissed the first AI alert were 60% less likely to engage with subsequent alerts — even when the predictions were accurate. First impression of the AI was decisive.
"Surface stress predictions in the UI with intervention prompts at the right moments."
The engineering team had a working model. The brief assumed UX was the delivery layer — make the predictions visible, make the prompts accessible, add good animations. The hard problem was already solved.
"An AI intervention that arrives uninvited, with no legible reasoning, at a moment of vulnerability, is not a wellness feature. It's an intrusion."
Users in distress have degraded cognitive capacity. An AI that they don't understand — acting on signals they can't verify, at moments when they're least able to evaluate it — generates anxiety, not relief. Trust had to be built before distress hit, not in the moment of it.
We weren't studying stress — we were studying the relationship between a vulnerable human and an AI they didn't yet understand.
18 participants logged their emotional states alongside app interactions for 14 days. Critical finding: users who felt the AI "got them" early in the study (Week 1) maintained engagement for the duration. Users who had a confusing early experience (unexplained alert, wrong moment, dismissal) never recovered their engagement — even when later predictions were accurate.
Asked participants to open the app while recalling a recent stressful event and verbalise what they were seeing and feeling. Revealed: users experiencing acute stress showed dramatically reduced attention span, lower tolerance for decisions, and heightened suspicion of anything that felt "pushy" — even gentle interventions. Design had to work with degraded cognition, not against it.
The 72% first-alert dismissal rate. 60% post-dismissal engagement drop. Average time-to-dismiss: 2.3 seconds — too fast to have read the intervention content. Users were reacting to the alert format, not the alert content. The design of the interruption itself was the problem, not the message inside it.
Interviewed 4 mental health practitioners on how therapeutic trust is established — particularly in moments of crisis. The insight: trust in a therapeutic relationship precedes the crisis. By the time someone is in acute distress, the relationship has already been built — or it hasn't. The same principle applied to AI: trust had to be built in calm, so it was available in crisis.
Each principle was derived from research — a direct translation of what we learned about trust, stress, and AI legibility.
The onboarding experience was redesigned to build trust before any AI prediction was made. Users learned the signals the AI watches, saw example detections, and calibrated sensitivity — before their first stress event. Trust is pre-loaded, not reactive.
Every AI intervention showed its reasoning in plain language — not "AI detected elevated stress" but "Your heart rate has been elevated for 12 minutes and you have three back-to-back meetings next hour." Prediction accuracy matters less than user understanding.
Intervention prompts required zero decision-making. No "choose from these 5 techniques." One suggestion, automatically selected for context, requiring a single tap to begin — or none at all if the user wanted to dismiss. Cognitive load eliminated at the critical moment.
Users could inspect, override, or dismiss any AI prediction with a single visible action. The AI never acted without being visible — every biometric signal being used was surfaceable. Transparency over opacity, even for users who never used it.
The platform had to serve all three without designing for none.
Already overwhelmed when the app opens. Needs intervention in under 3 taps. Any friction = app closed. The constraint that shaped the entire interaction model.
Engaged in calm state, reviewing history, building insight. Wants depth, wants data, wants to understand the model. The analytics layer was designed for this user.
High privacy concern, high AI scepticism. Needs to see data source, prediction logic, and manual override before any engagement. The transparency affordances were designed for this user — and benefited everyone.
Five key screens from the final platform — from initial discovery through the complete client-facing experience.
The engineering team had shipped a working stress detection model and handed UX the brief to "design the experience around it." After the first week of diary study data, it was clear the problem was trust, not UI. I reframed the project scope from "UI for the model" to "trust architecture for AI wellness" — a significant scope change that required executive buy-in. The beta engagement data was the argument: 72% first-alert dismissal wasn't a UX quality problem. It was a trust architecture problem.
Product had a strong conviction that a rich personalisation dashboard — where users could tune sensitivity, set preferences, customise their AI — would drive engagement. The think-aloud sessions told a different story: users in distress had no tolerance for settings screens, and users who needed personalisation most were least likely to configure it. I recommended cutting the feature from v1 scope and replacing it with progressive AI calibration — the model learns from interactions without requiring user configuration. The decision was resisted initially, but the think-aloud data won the room.
Two weeks before beta launch, one of the clinical experts we'd interviewed reviewed our intervention flow and flagged a risk: for users experiencing clinical anxiety, a sudden AI notification — even well-designed — could trigger a stress response rather than relieve one. The intervention model needed a "breathing room" delay — a short pause between AI detection and notification delivery, during which the system checks whether biometrics are recovering naturally. A minor technical change. An important safeguarding decision.
All metrics from beta program (n=34). Results represent test environment conditions.
We brought in clinical experts for review — but in Month 3, after the core interaction model was already built. The breathing room delay (the most important safeguarding decision on the project) was identified in that review. Had the clinical consultation happened in Month 1, it would have shaped the interaction model from the start, not required a late intervention. Any product designed for mental wellness should involve clinical expertise from day zero.
We designed for the sceptic user, but we studied them obliquely — through think-aloud sessions and beta analytics, not dedicated research. The transparency affordances we built were good, but they were informed by inference rather than direct study of high-AI-scepticism users. A dedicated research track with participants who actively distrust AI would have produced sharper, better-informed transparency design.
The final design treated trust as something you build once in onboarding. Post-beta interviews revealed trust fluctuates — users who had a bad experience with an inaccurate AI detection (it flagged stress when they were fine) needed a rebuild pathway. We didn't design for trust recovery. A "why was this wrong?" feedback mechanism that visibly influenced future predictions would have been valuable — both for user trust repair and model calibration.