Телемост: диагностика звука микрофона и динамика
Телемост — сервис видеозвонков для b2b и b2c. Это молодой, активно развивающийся продукт, с DAU > 1 млн пользователей.
Контекст
Перед подключением и во время звонка пользователи не могли проверить микрофон и динамик. Это приводило к ошибкам в начале звонка, фрустрации и обращениям в поддержку.
Задача
Добавить быстрый и понятный способ проверки устройств, чтобы:
— снизить количество неуспешных стартов звонка
— уменьшить нагрузку на поддержку
— сократить негативный пользовательский опыт в критическом сценарии
— снизить количество неуспешных стартов звонка
— уменьшить нагрузку на поддержку
— сократить негативный пользовательский опыт в критическом сценарии
Моя роль
– спроектировала UX-сценарий проверки устройств
– провела бенчмарк-анализ и сформировала продуктовые гипотезы
– разработала прототипы и подготовила к тестам
– приняла решение по финальному UX на основе данных
– подготовила решение к разработке, защитила перед PO
– провела бенчмарк-анализ и сформировала продуктовые гипотезы
– разработала прототипы и подготовила к тестам
– приняла решение по финальному UX на основе данных
– подготовила решение к разработке, защитила перед PO
- Погружение
В текущем сценарии пользователь мог выбрать устройство, но не мог проверить его работоспособность.
Настройки звука до внесения изменений
Команда разработки сразу предложила свой вариант с кнопками и шкалами индикации. Это решало задачу технически, но выглядело сложно для восприятия и не соответствовало привычным сценариям проверки звука, поэтому я инициировала поиск альтернатив и проверку решений на пользователях.
Интерфейс, спроектированный командой разработки
2. Бенчмарк
Анализ конкурентов показал, что сценарии у многих перегружены, часто используются дополнительные окна и нестабильные паттерны. Телемосту же нужен минималистичный и линейный сценарий без усложнения.
3. Проектирование решения
Я разложила задачу на 2 сценария: проверку динамика через воспроизведение звука, и проверку микрофона через запись и прослушивание голоса. Решила использовать привычные паттерны — цветовые индикаторы для проверки работоспособности и запись голоса в микрофон.
Дополнительно провела быстрый опрос коллег и подтвердила гипотезу: пользователям важно слышать как звучит их голос, чтобы понимать, хорошо ли их слышно, например, из микрофона наушников или с включенной функцией шумоподавления.
Сделала несколько вариантов интерфейса, важно было найти баланс — не утяжелять интерфейс текстом и при этом сделать его максимально понятным.
4. Проверка гипотез юзабилити тестом
После ревью макетов решили протестировать на пользователях 2 варианта: первый — с иконками и текстом в кнопках, второй — только с иконками. Для тестов я составила список интерфейсных гипотез, собрала кликабельный прототип и передала исследователю в сервисе Pathway.
По результатам немодерируемого юзабилити теста на 100 респондентов, в кнопках с иконками только 27% поняли функцию записи голоса, и 26% — функцию воспроизведения звука. Это означало, что кнопки с иконками без подписей не работают в аудио-сценариях, и я решила оставить подписи.
5. Подготовка и запуск
Доработанное решение я перевела на компоненты новой дизайн-системы, проработала корнер-кейсы, синхронизировалась с разработчиками и защитила решение перед продакт оунером.
Финальное решение на проде. Реализацию можно увидеть на вкладке «Звук» в настройках.
6. Проактивное развитие сценария
Также я предложила расширить функциональность и добавить проверку на экран подключения и в интерфейс звонка без перехода в настройки. Это позволит предотвратить ошибки при подключении и сократить путь пользователя в случае внезапной проблемы со звуком. Концепты задокументировала для дальнего развития продукта.
Результат
Функция внедрена в прод, сценарий проверки стал доступен до и во время звонка. Снизилось количество обращений в поддержку по проблемам со звуком.
В сторах пользователи перестали писать отзывы, связанные с этими проблемами. Решение закрыло критический UX-разрыв в одном из ключевых сценариев продукта.
Корнер-кейсы
Рефлексия
Что сработало: я укрепила навык аргументации дизайн-решений — команда разработки пришла с готовым решением, пришлось отстаивать пользовательский сценарий и инициировать проверку гипотез. Получила хороший опыт работы с исследованиями — сама подготовила прототип в Pathway и использовала результаты за основу решений. Защитила решение перед PO, презентовала не просто интерфейс, а логику решений и их влияние на пользовательский опыт.
Что сделала бы иначе: на этапе формирования гипотез опиралась на опрос коллег, а не на реальных пользователей — в условиях сроков это было оправдано, но в идеале хотелось бы проверить сценарии на настоящей аудитории. Также заранее договорилась бы с командой о метриках: зафиксировать количество обращений в поддержку и динамику отзывов до релиза, чтобы после можно было показать измеримый результат, а не качественные изменения.
