Redesigned the therapy video call so a shaky connection or a missed check-in never means losing the session, cutting connection complaints by 40% in the first month.
Role
Sole Product Designer
Team
1 PM, 1 Analyst,
5 Engineers, 2 QA
Industry
Health Tech
B2B2C Mental Health
Timeline
Jan – May 2026
Overview
Intellect connects users with therapists and coaches for 1:1 video sessions, often the first time a user has ever spoken to a mental health professional. The stakes are high and the margin for friction is essentially zero. I redesigned the video session experience across the user app, user web, and provider web to close two compounding gaps: no visibility into connection issues, and no way to complete a pending mental health assessment without leaving the call.
Background
The session was the product, and it had no fallback. By Q4 2025, two separate but related problems had accumulated into a real reliability gap. There were no in-product diagnostics when a call started failing, users discovered problems mid-session with no idea what was wrong or what to do, and failed sessions cascaded into credit refund requests and provider no-show disputes.
Separately, providers assign mental health assessments before a session, but if a user hadn't completed one, the only path was to leave the call, complete it, and rejoin, disruptive enough that in practice it was almost always skipped. These weren't really two product problems. They were the same problem: the session had no resilience. When something went wrong, technical or procedural, users were on their own.
Problem
~379 support tickets in six months cited audio/video failures (~259) or dropped connections (~120), with zero in-product diagnostics to explain any of it to the user in the moment. Google Meet, Zoom, Slack, and Preply all ship real-time connection diagnostics as standard; Intellect shipped none. Meanwhile, assessment completion during a session was effectively broken by design, the only path to complete one required leaving the call entirely.
If users can see what's wrong and know what to do, they'll stay in the session instead of leaving it. Can we give them that, and make a pending assessment something they finish without ever losing the session?
Process
Starting with the competition
Before opening Figma, we audited how tools our users already knew handled connection problems: Google Meet, Slack Huddle, and Zoom, each with a very different philosophy. Slack exposes latency, jitter, packet loss, and CPU usage in a panel built for engineers. Google Meet shows connection delay as a live graph. Zoom walks users through a step-by-step audio check. The observation that shaped everything: our users aren't technical. A therapy user mid-session doesn't need to know their packet latency is 180ms, they need to know their connection is unstable and that closing a browser tab might help. The right level of detail for Intellect was simpler than what any of these tools were showing.
First prototype: built to learn, not to ship
Rather than spending weeks on high-fidelity files before anyone had seen the idea, we built a rough prototype quickly to get something stakeholders could react to, the goal was getting engineering in a room with something concrete, not showing finished design. That first call with engineering was where the real scoping happened: we walked in with a prototype, we walked out with a significantly tighter brief.
Ideas we scoped down, and what we kept instead
Several designed features didn't survive the tech feasibility conversation, each taught us something about the right level of complexity for a mental health product:
Dual network status display (user + provider). The original design showed both participants' connection quality simultaneously. Daily.co doesn't expose the other participant's network data to the client without a separate backend pipeline, so we dropped it. Telling a user their therapist has a bad connection is distressing and unactionable anyway.
Audio-only auto-switch on poor connection. Pushed back by engineering as high effort at this stage. We kept a camera-off shortcut in the Connection Details panel instead, same outcome, lower engineering cost, and the user stays in control rather than the system deciding for them.
Video feed repositioning when the assessment sheet opens. Achievable, but would have significantly extended the timeline. Since the core fix was making assessments completable in-session at all, we deferred the repositioning as a follow-up enhancement.
Hardware input selection on mobile. The early prototype included dropdowns to select microphone, speaker, and camera before the connection test. On mobile, the phone's built-in hardware is the only real option, so we removed the fields entirely and the pre-call screen simplified considerably.
Fast feedback, faster iteration
After the feasibility call, we reworked the screens and got them in front of the team again quickly: two rounds of iteration, one approval, straight into grooming. The time between "here's the revised design" and "engineering has a spec to build from" was under a week, achievable because the scope was tight and the constraints were already known.
The one pushback we held firm on: engineering raised the pre-join preview screen (seeing yourself before joining, confirming your camera works) as high effort. We pushed back anyway. It's standard on every platform users have experience with, shipping without it would have felt off even to users who couldn't articulate why. We kept it.
UAT: breaking connection on purpose
Testing the connection-quality feature hit an immediate practical problem: how do you reliably reproduce unstable or poor network states to verify the UI triggers correctly? Waiting for a bad network to happen naturally wasn't a testing strategy. I set up Network Link Conditioner, a macOS/iOS developer tool that throttles network conditions at the device level, worked with QA to define profiles matching the three connection states our design targeted, and used those shared profiles throughout UAT so the whole team was reproducing identical conditions on every device. Two real mismatches surfaced this way: the toast was firing below the threshold that should have triggered it, and the red dot on the network icon wasn't clearing when the connection recovered. Both were caught and fixed before release. Stepping outside the pure design role to understand the testing infrastructure well enough to participate in it produced a better shipped product.
Final Product
Feature 1: Connection Quality
No more silent failures, users see what's happening, right when it matters.
Pre-call: test before you commit.
A "Test connection" option on the pre-join preview screen, always optional, never blocking entry. The test returns one of three states, Good (no tips needed), Unstable (actionable tips shown), or Poor (same tips list), and since test duration differs by platform (15–20 seconds on app, 1–1.5 minutes on web), that duration is surfaced upfront so users know what to expect before committing to wait.
In-session: passive monitoring, active nudge.
The system monitors connection quality continuously in the background. When it degrades, two signals fire together: a red dot on the network icon in the toolbar, and a toast prompting the user to tap it for help. Tapping opens a Connection Details panel with current status and a prioritized recommendation list; for unstable connections, it also surfaces a one-tap shortcut to turn the camera off, the single most effective recovery action, without ending the call.
Feature 2: In-Session Assessments
Completing an assessment shouldn't mean leaving the session. The key constraint: video calls run inside a Daily.co iframe, so custom UI couldn't be injected directly into the video layer. Any assessment UI had to sit as a separate overlay, which produced the cleaner solution: a bottom sheet on mobile, a side panel on web, both keeping the session video visible so users never feel like they've left.
User side.
A toast appears when a user has a pending assessment. Tapping opens it as a bottom sheet with the video still visible above. Users move through questions, see results, and dismiss, all without leaving the call. A quit-confirmation intercepts anyone trying to close mid-way; the easier path (Continue, primary dark CTA) is also the more prominent one, with "Leave for now" as a secondary outline button.
Provider side.
An Assessments section added to the right panel of the video call interface, alongside case notes. Providers see pending assignments, send a reminder nudge, and load results once completed, all without leaving the session. Language throughout uses "assessments" rather than naming a specific instrument (like PHQ-4), so the system works for any assessment type added in the future.
Impact
Both features went from problem framing to production between January and May 2026, design, engineering, UAT, and launch across three platforms simultaneously, with zero post-launch rollbacks.
~40% reduction in connection-related support tickets in the month after launch, consistent across the following weeks, not a one-week blip.
~3x increase in assessment completion rate during live sessions.
+0.4 improvement in post-session technical experience feedback score.
Assessment completion was straightforward to measure directly. Connection quality improvement is harder to isolate cleanly on its own, but the ticket-volume drop held steady well past launch week.
The one that got away.
A separate, lower-volume but genuinely bad experience kept surfacing: users who joined on time, had a good connection, completed their assessment, and just sat there waiting, because the provider hadn't joined. There was no in-product path for this at all, no timer, no prompt, no way to flag it without leaving the session to contact support. We sketched a flow (detect the provider hasn't entered after a set window, surface a prompt, let the user alert the care team with one tap) but it didn't make this release. It's flagged as the clear next problem to pick up.
Reflection
Designing for invisibility:
These features are infrastructure, not interface, users shouldn't notice them. The connection test should feel routine, the assessment sheet should feel like a natural part of the session, the network alert should feel like help rather than alarm. The hardest part wasn't designing the UI, it was deciding what not to show. The connection panel could have exposed jitter, packet loss, and latency figures the way Slack's does. We didn't. Therapy users are not infrastructure engineers, and the right information density for a mental health session is different from the right density for a developer standup.
Session continuity as a design value:
The assessment work made me think seriously about continuity: every moment where a user's attention shifts from their therapist to a UI element has a cost. The challenge was making completion feel effortless enough that users could return to the conversation without losing the emotional thread.
What I'd do differently:
I would have pushed harder for the pre-join screen to show whether the provider had already entered the room. That information exists, the backend already knows it, and surfacing it at the exact moment a user is deciding whether to join would have addressed a real anxiety: am I about to walk into an empty call? It came up during the design process and was flagged as worth exploring, but given the timeline and scope of this release, it got pushed to the backlog rather than built.
