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