Pre-Join Flow

Video banking web application - Coconut Software

Project Overview

The first screen banking customers see when joining a video banking appointment can make the difference between a converting a new customer and maintaining continued loyalty or receiving a bad review or losing a customer to another institution. This screen (the pre-join screen) is the place where they configure their video and microphone settings and catch equipment errors that may hinder them from having a successful video banking appointment.

Coconut Connect's pre-join screen had number of problems that needed resolving:

Users had no way of telling whether their microphone was working, a critical ingredient for a successful meeting.
The experience did not indicate prominently enough that there was an error with any of the input devices and it relied solely on documentation located in a separate page to guide the users on how to resolve the errors.
The functionality to choose a different microphone, speaker or camera, a functionality that was critical for financial advisors who may not use their default input or output devices, required multiple clicks to access and was often missed.

Skills Demonstrated

Design Process

UX Design

Tools Used

Figma

Figjam

Previous State

this is a screenshot of the pre-redesigned application with notes on Figma on the issues that I needed to work through

Exploration session with the devs

The first step I took was organizing a mini design sprint with the 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