Привет! Я - Инга, старший UX-исследователь в Атоме.
До этого два года разбиралась в роли CJE, как научить ИИ понимать людей, а последние полтора года проектирую голосового ассистента для электромобиля в команде Voice&Sound.
Мне всегда нравились сложные продукты и роль защитника пользователя. Но в мире разработчиков и менеджеров, где правят код, дедлайны и технические метрики, нас не всегда слышат.
В этой статье-рефлексии хочу углубиться в тему и попробовать разобраться, как можно найти выход из этой ситуации.
Поехали!
В чем сложность?
Бум сложных технологий создал реальный спрос на UX-исследователей. Компании понимают: нужно думать о пользователе, даже в самых технических продуктах.
Но есть трудности при встраивании такого спеца в командах.
Первое: релизные циклы имеют жесткие сроки. Есть дедлайны, есть функции, которые нужно реализовать. Мы на пороге выпуска автомобиля — любая активность оценивается через призму срочности и прямого влияния на продакшн.
Второе: разработчики и инженеры фокусируются на своих задачах. Инженер ML оптимизирует точность модели. Звуковой дизайнер — качество синтеза. Дизайнер интерфейса — удобство взаимодействия. Каждый видит свой кусок системы.
Это не противоречие — это естественное разделение ответственности.
И третье: в сложных системах метрики успеха не всегда очевидны. Как измерить естественность голоса? Как доказать, что пользователь понял команду?
Как перевести это в язык, который поймет разработка? Эта связь между техническими решениями и опыто�� пользователя требует перевода.
Решение: стать частью технической машины
1. Говори на языке команды (и становись T-shaped)
Это не значит стать инженером. Это значит разбираться в том, о чем говорят твои коллеги.
В моем случае — понимать основы обработки естественного языка, ограничения распознавания речи, важность диалогового дизайна, как работают голосовые движки,
что происходит с данными после того, как я их собрала. Иногда мы даже заходим на сторону QA — анализируем логи ошибок, отслеживаем баги распознавания, видим, где система падает.
Вот тут важный момент. Исследователь — это не QA, конечно. Но в технических командах грань стирается. Мы не проверяем функциональность, но мы видим, где система ломается
с точки зрения пользователя. И эта информация критична для разработки.
Это и есть суть T-shaped исследователя: глубина — в своей дисциплине (качественные
и количественные методы, аналитика), но широта — в соседних областях: от технической архитектуры до операционных процессов.
Когда инженер видит, что ты не просто слушаешь, а понимаешь его боли и ограничения,
что ты можешь разобраться в логах и помочь диагностировать проблему — доверие растет.
Он готов учитывать твои рекомендации.
2. Развивай двойную эмпатию
Да, эмпатия к пользователю — это главное. Но теперь критически важна еще и эмпатия
к командам: к разработчикам, которые спешат; к дата спецам, которые оптимизируют модели; к смежным командам, которые зависят от нас.
Поймешь их боли, ограничения, рабочий контекст — получишь основу для построения доверия. Вместе сформулируете исследовательские вопросы, которые реально влияют
на продукт.
С разработкой обсуждаем, где я могу быть полезна: какие показатели валидировать,
как организовать данные, какие выводы помогут им принять решения. И важно, что в нашей профессии часто работают психологи — пора применять свои скиллы :)
3. Проводи исследования, которые дают реальные ответы
Вот какие методы мы используем — и они действительно работают:
Тестирование диалогов методом Гудвина. Не просто слушаем — вовлекаем людей
в интерактивное взаимодействие. Видим, где ломается диалог, где люди не понимают помощника, где ему не хватает контекстаКомплексные тестирования со всеми функциями. Это не отдельные тесты
— это полный сценарий использования автомобиля. Люди работают с голосовым помощником в том контексте, в котором им нужноСбор естественной терминологии. Спрашиваем: как ты бы назвал эту функцию?
Как ты попросишь помощника это сделать? Потом эти данные правятся в аналитике
и передаются разработке. Голосовой помощник будет понимать реальный язык пользователя, а не только то, что мы придумали в офисеКоличественные тестирования по стандартам. Используем усредненную оценку мнения (MOS) и показатель ошибок распознавания — метрики, которые понимают разработчики и бизнес. Это объективные данные, а не просто «нравится»
или «не нравится». Они станут нашей базой для сравнения, когда выпустим автомобиль и получим реальные данные от пользователейСбор интентов и сценариев. Собираем, какие команды хотели бы использовать пользователи, какие сценарии для них критичные. Это помогает расставить приоритеты при разработке
4. Будь гибким и быстрым
Иногда можно забыть про длинные циклы исследований и использовать легкие методы:
Экспресс-интервью (20-30 минут) с пользователями или коллегами
Анализ логов и данных — почему пользователи повторяли команду, что пошло не так при распознавании речи
Экспертная оценка и сравнительный анализ. Пошли и вместе с командой сами потрогали и прогнали на тестовом стенде
Это дает достаточно информации для решения и обсуждения с командами.
Главное — быстро реагировать и передавать данные.
5. Встройся в процессы, а не жди запросов
Ключ к изменению восприятия — активная интеграция.
Участвуй в планировании спринтов и кварталов. Обсуждай, какие исследования нужны
и почему. Формулируй исследовательские гипотезы вместе с командой: не я придумываю,
а мы вместе.
Не стесняйся «влезать» в технические дискуссии. Когда обсуждаете диалоговый дизайн, архитектуру распознавания, приоритеты функций — активно напоминай: «Как пользователь это поймет? Что произойдет, если сломается эта часть?
Видели ли мы это в тестированиях?»
Держи руку на пульсе: участвуй в стендапах, общайся с разработкой, если вдруг ты
не рядом. Изучай литературу и статьи, следи за пабликами в соцсетях по теме.
Делись инсайтами постоянно и кратко. Не жди идеального отчета — быстрые сводки, слайды на 1 минуту, посты в рабочие чаты часто работают лучше.
Твоя уникальная ценность: видеть целое
В сложных системных продуктах разработчики часто видят только свой модуль.
Исследователь видит целое. Ты выступаешь мостом между абстрактными техническими возможностями и реальными человеческими потребностями. Ты видишь, как части системы работают вместе через призму пользователя.
Это создает уникальную ценность, которую никто другой не сможет дать.
Вместо заключения
UX-исследователь в мире сложных технологий — это не «приложение к процессу».
Это стратегический интегратор, переводчик между мирами.
Идеально процесс выглядит на бумаге и в статье. В реальности — куда сложнее. Я описала выше про T-shaped скиллы, про двойную эмпатию, про встраивание в процесс. Но путь трансформации сложный и иногда неуверенный. Мы все учимся адаптироваться в этом новом времени, пробуя разные подходы. Ключ — в открытом диалоге с коллегами
и руководителем.
Что дальше?
Впереди новый большой вызов. Голосовой ассиcтент должен стать умнее. Это уже не просто распознавание команд — это о том, как люди будут общаться с искусственным интеллектом в автомобиле.
И мне очень хочется ступить на этот новый путь. Конечно, не одной, а за руку с командой. Вместе переосмысляя и экспериментируя.
Но это уже совсем другая история :-)
