Audio & Video Calling

Safe, reliable communication between co-parents and their children.

View Presentation Deck

Problem

Co-parents need a way to call each other to facilitate parent-to-child virtual visitations. This problem has only gotten worse since the COVID-19 pandemic. How might we design a calling system designed to handle co-parenting intricacies, such as navigating trauma and healthy boundary setting?

Solution

• A transparent, easy-to-use consent system. Co-parents will only be able to call each other if both agree to use the feature.

• Use Voice Over Internet Protocol (VOIP) technology instead of traditional calling methods. This allows co-parents to call each other without sharing their phone numbers.

• Unalterable, detailed documentation for the activity that happens during the call (mute/unmute, camera on/off, etc).

• Recordings and transcripts of calls available to end users in a future release.

Business Impact

The Beta release of this feature surpassed the company’s adoption goal by 140% and has created a 6% increase in ARPU.

Role

I led the design from start to release, incorporating feedback from our users, my design team, product team, and stakeholders along the way. Platforms include responsive web, iOS, and Android.

Research

Competitive Analysis

Our Product Management and Marketing team conducted a thorough competitive analysis on which co-parenting and family management apps offer documented calls. Some of these competitors offered only unrecorded calls; some offered all-recorded calls. Some did not offer calls at all.

We were left with the following question:

How important is it to users that calls be recorded?

Survey

To answer this question, my team and I chose to send out a survey to OurFamilyWizard users to learn. While the results of the survey are confidential, we learned:

• A consenting system is important. Calling is a sensitive topic for co-parents and some may be triggered by the idea of their co-parent being able to call them.

• Most prefer the calls to be recorded in case abusive behavior happens during the call.

Rapid Sketching & Iteration

Meanwhile, I sketched concepts and invited speedy feedback from my design team and Product Manager. The goal was to land on a user interface that was easy to navigate, easy to learn how to give calling consent, and easy to understand how to place a call.

Each day, I iterated on my previous day’s work, incorporating my team’s feedback along the way.

Mid-Fidelity Prototyping

I moved to mid-fidelity wireframing in Figma where I created an interactive prototype to test the usability of the onboarding flow, consenting to place/receive calls, placing a call, and viewing call details.

I created local Figma components to speed up my process. Many of these components made their way into the company’s iOS design system, which is early in its development.

User Interviews & Usability Testing

To dig deeper, I scheduled 7 moderated interviews with people who responded to our survey. I aimed to include participants that indicated they wanted calls, as well as participants that indicated they did not want calls. Overall, we wanted to learn if my initial design concept for this feature met the needs of OurFamilyWizard users. Specifically:

• Do users understand how to use this feature?

• Do unrecorded calls meet the needs of our users?

• Is this feature triggering for users who do not want to call their co-parent?

• Is it clear to users they can turn off their consent to place and receive calls?

While we don’t have quantifiable data on how many co-parent relationships are in domestic violence cases, we do know that victims of domestic violence use our product. Therefore, we have to be especially careful to keep their experience in mind while designing. I use trauma-informed design principles to help guide designing experiences that aim to do the least harm to our users.

Scripts

I wrote two scripts, one for users who want calls and one for users who do not want calls. I first interviewed each participant and later went into a usability test with the mid-fidelity prototype I created. The prototype I used in the usability test section was intentionally designed to not include recording. We wanted to see for ourselves if this is something participants would bring up on their own.

We Learned:

• Most participants indicated they would only use voice/video with their co-parent if calls were recorded. 

• Most expected to pay more for the feature, but only if the calls are recorded.  

• Some would not expect to pay more because they already feel cornered by being court-ordered to use the product. 

• The onboarding flow I designed to lead the user into the feature became redundant and cumbersome for most users.

Design Iterations, Polish, & Handoff

From user testing, one user flow needed to be modified: user onboarding. After making adjustments to this flow, I refined the UI design, moving the mid-fidelity wireframes to high-fidelity to prepare to handoff the designs to our development team.

Bringing In Sound Design

At the company’s approval, I drew on my music background to custom design the sounds for this calling feature. I aimed to make clear what the sound was communicating while being pleasing to listen to. I used Logic Pro X and a mix of electronic and acoustic instruments to create these sounds.

Beta Launch

The launch of the beta version of this product offering went to 9,000 new users. For this feature to be used, both co-parents must provide their consent. Once both parties’ consent is given, they can place and receive both audio calls and video calls. Because of this nuance, the company anticipated about 5% adoption during the Beta phase.

We were surprised to find nearly 12% adoption, 140% higher than expected!

Evaluative Feedback

I created an in-product feedback loop for users to let us know how their call quality was, as well as a freeform text box to provide us with their general thoughts on the solution. The business was interested in learning how to best market this product to co-parents, so we included a few questions that helped us understand that their primary purpose might be for using this feature. This feedback loop involved two short surveys: one accessible via voluntarily pressing a “provide feedback” button in the feature, as well as a simple rating dialog after a successful call was completed.

Survey 1: Post Call Quality
Q1: Please rate the quality of your call (scale of 1=Poor to 5=Excellent)
Q2: Please explain (free form)
Q3: What was the primary purpose of your call? (select one)

• To talk with my co-parent

• To talk with my child(ren)

• To talk with both my co-parent and my child(ren)

• Other

Survey 2: Voluntary Feedback Survey

Q1: How would you rate your experience using OurFamilyWizard Calls? (scale of 1=Poor to 5=Excellent)
Q2: Please explain (free form)
Q3: What type of calls do you plan to use? (select one)

• Audio Calls

• Video Calls

• Both

• I don’t plan to use calls

Q4: What is your primary reason for wanting to use OurFamilyWizard Calls?

• To talk with my co-parent

• To talk with my child(ren)

• For my children to talk with my co-parent

• To talk with another family member or caretaker

• I don’t plan to use calls

• Other (please explain)

Q5: In what situations do you prefer using OurFamilyWizard for calling more than other means of communication? (free form)
Q6: In what situations do you NOT prefer using OurFamilyWizard for calling more than other means of communication? (free form)
Q7: How important is it for you to be able to record your calls through OurFamilyWizard? (scale of 1=Not at All to 5=Very Much)
Q8: Please explain (free form)
Q9: Anything else you’d like us to know?

We Learned…

From our evaluative feedback surveys, we learned that a few small tweaks needed to be made to improve the end user’s experience before we went to market. These improvements included:

1. Unstable Internet Connection Notification

   Why? Users had a difficult time understanding why their calls were blurry or low quality. Indicating to the user that this is due to their internet connection helps them diagnose and solve the issue themselves.

2. Missed Call Notifications
   Why? In an effort to slim down our development time, our team had to postpone building out missed call notifications. We learned early on that these are necessary to the user experience of the feature; users felt upset and misinformed if the app didn’t make them aware of their missed calls.

3. Device Permissions Revisions
   Why? Both iOS and Android handle device permissions (access to camera, microphone, etc) differently. In the edge case that a user does not accept permissions or turns them off in their settings, we needed a way to communicate to the user that these are necessary for the feature to work.

4. Small Adjustments to the Activity Log
   Why? We learned that users want to see the time of their call included in the Activity Log list. This helps them find the call they are looking for in a long list.