Multi participants audio

Multi Participants Audio

Strigo is an application that provides the ability to organize events that educate learners about products. Previously, events were conducted in a one-way communication format where the presenter spoke and the learners listened. However, the new feature allows for open discussions during the event. As the lead designer, my role involved overseeing the entire design process from conceptualization to research and rollout. The project was executed by a squad, and I worked closely with product managers, engineers, sales, marketing, and other stakeholders to ensure that everything was done smoothly.

Role

Design lead

Company

Strigo - startup

Duration

Apr – Aug 2020

Scope

New feature

The problem

Strigo’s communication was limited to one-way audio, with only the presenter being able to speak.
Users tried using communication apps alongside Strigo but found using two products for an event to be complex.

The goal

Enable users to have group discussions during events with multiple participants.

Balancing between velocity and UX

Before designing, we had to decide whether to allow manual permission for multiple speakers or implement a solution for multiple presenters/open discussion. Quick entry vs. long-term benefits. We chose an open Zoom-like discussion format for our events to provide a better user experience and meet our bigger vision. Engaging the learners is crucial, and an open discussion format is the best way to achieve this. However, this implies that we have to make some other trade-offs in terms of user experience.

Modifications required for the old communication panel

The previous communication panel only allowed for one-way audio with the presenter being the only one able to speak. The only option for two-way communication was through chatting.

Example of prototype features that were not included in the MVP

Overview of the redesign

Adding multiple audio communication functions was a challenging task for the entire team. As a designer, I realized that we needed to add more features to the communication apart from the basic ones like adding audio buttons. However, with limited resources as a startup, every change required me to get buy-in from stakeholders by convincing them that it was necessary.

The new communication panel

Learners and trainers should have distinct experiences

With the addition of audio, I saw the need to make more changes to differentiate between the training team and the learners. This required getting buy-in from the engineering team and product manager.

Learner view vs. presenter view

Displaying audio and camera buttons to learners when the event is muted: necessary or not?

It was a dilemma: If the presenter didn’t want an open discussion in the event, there was no need to display the audio and video buttons to the learner since the event would be muted at all times. However, our assumption was that most events would require an open discussion since our users’ most common request was for higher engagement in events.

We kept the buttons visible but disabled. To make them more communicative, we added a tooltip that explains their state on hover.

Learner view vs. presenter view

Trade-offs

1

The chat was not connected to the attendee list

An attendee list is valuable for users to view who’s in the event and whose mic is active. However, connecting it to the chat required extra effort. So, I prioritized an open discussion format over the attendee list connected to the chat.

2

Only speaker view
without grid view

Now, we needed to decide on the MVP’s features. While determining the main features was easy, less obvious features like relocating and detaching the Academy posed a dilemma.

3

Disregarding alerts and
audio indication

After rolling out the alpha, we will realize that this trade-off was our biggest mistake. Sometimes, we cannot be too optimistic about network connections.

Restoring trust: communicating audio issues to our users

We released the first alpha version with a feature for our design partners but soon found a major flaw in our approach. We could not simply overlook errors and focus only on the best-case scenarios.

We soon discovered that errors, even if they are not related to Strigo, are still perceived as our system’s faults by users. So, we decided to take a step-by-step approach to tackle the issue. We started by identifying the most common errors that our users encountered and worked on communicating them more effectively.

Browser permission errors encountered before entering the event

Users can switch devices and check for proper functionality

Each device has an error indication

Connectivity indication

Connectivity alert

Impact

Widespread adoption of Strigo as a primary communication tool amongs Strigo's users.

Two major client acquisitions.

What I have learned

#1 Taking ownership of system problems

As customer experience professionals, we should keep in mind that system problems are our problems even if we did not cause them. It’s essential to remember the limitations of our technology and find ways to work around them.

#2 Prioritizing

Initially, I thought that separating the chat from the attendee list and using a different attendee list was a significant trade-off. However, it turned out that having meaningful discussions involving multiple participants was more essential. A few months later, we changed the chat accordingly.