Coconut Connect Pre-join Redesign

Reducing unrecovered media errors so more appointments start smoothly

Project Snapshot

My Contribution: I owned the design end to end: flows, UI, error copy, async Maze tests, and Pendo instrumentation. I partnered with PM on goals and with engineers on event names and QA. I facilitated design reviews with peers from adjacent teams.
Timeline: 8 weeks design, 1 sprint build, launched to all tenants
My scope: Flows, UI, error copy, async Maze tests, Pendo instrumentation and weekly readouts
Primary metric: Unrecovered media errors per 1,000 pre-join sessions
Result: 40% reduction over the first 8 weeks post-launch on traffic in the thousands weekly (Pendo)
Team: PM, 2 engineers, design reviewers from adjacent teams

Problem and Users

Problem

A high rate of Coconut Connect users hit a media error in pre-join and failed to recover. That stalled the call before it started and increased the chance the appointment would be missed.

Users and context

Bank customers joining video appointments from desktops and mobile browsers
Advisors who need calls to start on time
Support and admins who handle recurring device and permissions issues

Baseline and Constraints

Baseline

Source: Pendo event stream for pre-join interactions
Metric: unrecovered media errors per 1,000 sessions
Traffic: thousands of sessions weekly
Observation: error surfaces and recovery paths were hard to find or interpret

Constraints

One sprint for engineering
No staged rollout available
Support content could not be expanded for this release
Privacy and permissions prompts vary by browser and device

‍

Skills Demonstrated

Design Process

UX Design

Design Sprints

Tools Used

Figma

Figjam

Exploration session with the devs

The first step I took was organizing a mini design sprint with the software engineers to brainstorm on how we would resolve these problems for both the average user with low frequency of use and the financial advisor who was using this tool multiple times a day.

The session generated multiple interesting ideas (Screenshot below) that formed the basis of the design I came up with

This is a screenshot of ideas that were generated by the team brainstorming session.

Exploration of existing solutions

Next, I did a deepdive on how other tools solve this problem. Seeking to understand existing patterns and their applicability to the problem I was solving.

These are screenshots I gathered about how Google Meet solves the problem of input and output settings and configurations and the error states they show. One thing that jumped out at me was how they made it easy for the user to tell what their currently selected i/o devices were and a quick way to change them

These are the Zoom settings and the thing that jumped out at me is how easily the user can tell whether their microphone is working.

The Design Process

The use cases I needed to cover were:

Prominently warn the user when they are in a state that cannot allow them to join the meeting
1. Testing
2. Mic
3. Speaker
Allow the user to know if their microphone is picking up audio
To allow the user to mute or unmute themselves
Allow the user to turn camera on/off
Allow the user to select the Mic they want to use
Allow the user to select the camera they want to use
Allow the user to select the speaker they want to use
Allow users the ability to change their background

Started off with high level sketches trying to understand the information architecture I needed to adopt in different states of the application.

Case 1: How might we indicate that a speaker’s mic is on and working?

In this case, my explorations took me to different ways we can display audio signal visually as a way to let the user know that the microphone is working. As I worked, and concretized concepts that worked, I made them into components that would make it easier for me to bring the pieces together cohessively

The notes I was taking as I designed describe my thinking process, the items I was struggling with in the design and the decision I made.

Once I concretized a path for the mic level indicator, I explored different ways of displaying it and then converted it into components that I could use later.

Case 2: How might we indicate that there is a problem with mic and video settings?

The first element would be to let the user know that there is a problem using the most prominent buttons on the screen

Next would be to highlight and describe the problem using a prominent alert

And an additional modal when they arrive on the call and dismiss the browser prompts to authorize a microphone. Since users cannot join a call without a working microphone, highlighting this error prominently and in multiple ways seemed reasonable.

Case 3: How might we enable the user to select the input or output device they prefer?

The next challenge was figuring out how to elegantly display input and output hardware configuration settings in a way that does not clutter the design but is easily accessible to users.

The screeshots below with their accompanying notes describe my thinking process

Case 3: How might we enable the user to test their microphone and speakers?

The next challenge was to figure out how to enable users to use the configuration settings we just exposed to select the input and output hardware they want and test if it's working.

For this solution, we utilized the menu and below are the explorations and thought process from that

Previous State

A before shot of the pre-join screen

What Changed

1. Error messages that guide recovery

Clear labels and plain language
Inline actions to retry permissions or refresh devices
Link to admin guidance only when needed

2. Prominent device switcher

First-class control for input and output
One-click visibility of available devices
Interaction hints for common misroutes

3. Always-visible sound meter

Live input feedback before join
Encourages device checks prior to connecting
Reduces silent joins

Here's a prototype walkthrough of the final design.

▶ Explore the interactive Prototype

Lessons

Small scope can beat full redesigns
- A three-sprint overhaul was unnecessary. One sprint of targeted fixes delivered most of the value at a fraction of the cost.
- Decision rule: pick the narrowest change that moves the primary metric.
Instrument the real failure, not the proxy
- Primary signal was unrecovered media errors per 1,000 pre-join sessions from Pendo, not cosmetic quality or subjective “friction.”
- Measuring the exact failure state avoided bikeshedding on visual polish.
Make recovery actions visible at the point of failure
- Plain-language errors, an obvious device switcher, and an always-on input meter reduced guesswork and retries.
- Users need immediate, local actions more than long help docs.
Hypothesis first, then UI
- We framed hypotheses around error visibility, device switching, and pre-join audio confirmation before drawing screens.
- This kept solutioning anchored to measurable outcomes.
Validate with weekly snapshots, not one big readout
- Thousands of sessions weekly enabled simple week-over-week checks that we incorporated into our stand-ups.
- Sharing quick snapshots with PM and Eng sustained focus and kept scope stable.

Why it mattered

Faster time to value for customers and advisors starting calls on time.
Lower support burden from fewer unrecovered failures.
Lower engineering cost and risk by avoiding a multi-sprint rebuild.

‍