Час пользовательского теста в электромобиле — это несколько часов расшифровки вручную. Пока респондент выполняет задания в интерфейсе и отвечает на вопросы, исследователь фиксирует его действия, а потом вынужден превращать все сказанное в процессе в текст и выискивать в нем важные для работы моменты. И так с каждым участником.
Мы решили автоматизировать эту рутинную задачу, а в итоге начали развивать целое направление внутренних ИИ‑сервисов. Как транскрибатор стал отправной точкой этого пути и что бы мы сейчас сделали иначе, расскажу в этой статье.
Итак, приступим
Привет, меня зовут Майя Азарова, в прошлом — лид исследований пользовательского опыта онлайн сервисов, а сейчас я руководитель продуктового направления прикладного использования искусственного интеллекта в Атоме. В этой статье расскажу об одном из наших прикладных сценариев, который появился из реальной рабочей боли.
Немного контекста
Мы делаем электромобиль Атом и при его разработке проводится огромное количество различных тестов. Проверкой сценариев в движении и в статике, интервью и разработкой интерфейсов в машине у нас занимается отдельная команда HMX, и о том, как устроены эти исследования, коллеги уже рассказали:
10 тысяч поездок: статистика Атома обосновывает введение двухместного такси
Как UX‑исследователь находит свое место в технических командах
Так вот, каждый юзабилити‑тест, каждое интервью оставляет после себя часы аудио и видео. Записи с тестов — это основной материал для анализа пользовательского опыта. Также это фундамент для базы знаний компании. Без расшифровки эти материалы быстро становятся бесполезны, потому что редко кто будет пересматривать по 10–15 часов записей, чтобы найти, где пользователь не понял интерфейс или засомневался.
Варианты по расшифровке у нас были стандартные:
Бесплатные сервисы. Ограничения по размеру файла, а главное — непонятно, где в итоге оказываются наши данные с внутренних тестов. Да, бесплатно, но какой ценой?
Платные сервисы. Работают хорошо, есть договоренности про хранение и использование наших данных, но это постоянная статья расходов и зависимость от чужого решения. Если изменится тариф, функционал, политика компании или доступность сервиса, то наш процесс встанет.
Делать руками или локально. Ручная расшифровка — самый дорогой способ потратить время квалифицированного исследователя. Развернуть модель локально может не каждый: у исследователя есть своя работа, и не все готовы еще и настраивать свое решение.
Сначала мы жили на вендорских решениях. Потом посчитали, сколько это стоит в год, насколько мы к ним привязаны и решили собрать прототип внутри.
Прототип, который слишком хорошо зашел
Прототип был простой, и он мгновенно оброс пользователями: оказалось, что боль есть у всех, кто хоть раз записывал интервью или любые тестирования. Однако у него не было ни гибкости, ни запаса на развитие: каждая новая просьба на улучшение упиралась в архитектуру, которую собирали «на коленке».
Летом 2025 года мы приняли решение развивать его как полноценный продукт — по техническому заданию от самих исследователей. Это, наверное, самое правильное, что мы сделали: требования писали не мы, а те, кто будет пользоваться инструментом каждый день.
Ресурсов было немного, поэтому я собрала команду под конкретный срок и определенный функционал. Первую версию мы запустили через три месяца, как и договаривались с заказчиками.
А потом еще примерно три месяца ушло на стабилизацию, внутренние чек‑листы и согласования.
Регламенты, которых еще не существовало
Вот это оказалось главным сюрпризом.
Мы привыкли, что вывод сервиса в прод — понятная процедура: есть чек‑лист, есть требования безопасности, ты им соответствуешь и идешь дальше. С сервисом на базе ИИ так не получилось. Часть правил, по которым нас проверяли, писалась ровно в тот момент, когда мы проходили проверку.
Это не значит, что кто‑то что‑то не сделал вовремя, просто сами процессы в компании не успевали за технологией. Для планирования это означало, что срок «до прода» невозможно оценить обычным способом, потому что требования могли появиться уже после того, как ты подготовил документацию.
Если вы сейчас сами запускаете первый ИИ‑сервис в своей компании, расскажите в комментариях как вы прошли этот путь.
А если только собираетесь, то вот пара советов, которые звучат как база, но не всегда учитываются при первоначальном планировании.
Первое: закладывайте на согласования столько же времени, сколько на разработку или даже чуть больше.
Второе: идите к безопасности и юристам проактивно, то есть не с готовым продуктом, а на старте.
От одной команды ко всей компании
Первой аудиторией были исследователи пользовательского опыта (UX) — небольшая группа с очень конкретной задачей. Но транскрипты, краткое содержание встреч, кастомизированные отчеты по встречам нужны не только им.
Дальше пришли собеседования: рекрутерам и нанимающим менеджерам тоже важно вернуться к тому, что кандидат говорил и настраивать под себя резюме встреч.
Потом мы выкатили улучшения для обычных рабочих встреч — наш самый массовый сценарий. Здесь мы поняли, что продукт уже давно больше, чем «инструмент для исследований».
Сейчас на подходе шаблоны для отдела продаж и постпродажного обслуживания: у них свои форматы разговоров и свои требования к тому, что должно попасть в краткое содержание.
Ради чего это все?
При постоянных доработках и улучшениях легко потерять цель. А цель у нас одна — сделать Атом удобным для тех, кто им пользуется уже сейчас, и развивать продукт в будущем.
Транскрибатор для исследователей ускоряет цикл принятия решений по продукту, потому что освобождает больше времени на анализ и помогает собирать закономерности. В рабочих встречах — это инструмент про сохранение договоренностей и преемственность в принятии решений. Точный транскрипт, минутки со встреч с зафиксированными решениями и ответственными помогают поддерживать память компании и когда кто‑то уходит в отпуск или на больничный, контекст встреч не уходит вместе с этим человеком.
Для собеседований и обслуживания клиентов ценность в том, что транскрипты помогают сохранить то, что действительно было сказано, а не только то, что запомнилось. Это материалы для дальнейшего анализа и категоризации, которые необходимы для развития.
Человеческий фактор, который мы недооценили
Для транскрибатора мы использовали искусственный интеллект как при создании артефактов, так и для написания кода и админки самого сервиса. Технические риски мы просчитали и заложили, а вот человеческую реакцию — не до конца.
У нас в компании много энтузиастов ИИ, и казалось, что в команде общий взгляд на вещи. Но оказалось, что энтузиазм заканчивается ровно там, где начинается твоя собственная экспертиза.
Пока ИИ автоматизирует чужую рутину — это прогресс. Как только кто‑то предлагает передать ИИ работу, которой человек занимается десять лет, реакция может быть резко негативной, вплоть до отказа принимать результат в принципе.
Признаюсь честно, выстроить этот диалог с первой попытки у нас не получилось.
Вывод, который мы для себя вынесли: людей, область знаний которых затрагивается, нужно вовлекать в решения на самом раннем этапе, а не ставить перед фактом.
Если хотите показывать прототипы интерфейсов, собранные с помощью ИИ, то зовите дизайнеров и фронтенд с самого начала. Планируете писать или проверять код — стройте новый процесс вместе с бэкенд‑разработчиками.
И на старте договоритесь о трех вещах:
где ИИ применять можно, а где нельзя;
кто и на каком этапе проводит экспертное ревью;
как разрешаются конфликты, когда человек и рекомендации ИИ расходятся.
Разница между «смотрите, как мы автоматизируем вашу работу» и «давайте посмотрим ваши процессы и уберем рутину и те моменты, которые вас давно раздражают» — это разница между сопротивлением и участием.
Почему портфолио, а не набор сервисов
Транскрипты не цель, а первый шаг. Из них складывается проверенная внутренняя база знаний по всему, что компания уже изучила, а без такой базы любые внутренние ИИ‑помощники будут отвечать красиво, но бессодержательно.
Именно поэтому вместо серии разрозненных сервисов мы собираем портфолио внутренних ИИ‑инструментов и развиваем его вместе с экспертами из разных департаментов. По сути, из одного продукта выросло отдельное направление прикладного ИИ для сотрудников.
Чему мы научились и что осталось без изменений
Требования должны формулировать пользователи, а не ИИ. Сделать прототип стало быстрее и проще, но техническое задание для ИИ‑сервисов никто не отменял. ТЗ от исследователей сэкономило нам месяцы работы над ненужным функционалом, который мог бы показаться важным, если бы мы сами забрейштормили продукт «как чувствуем» или сделали это с помощью ИИ, без учета реальных пользователей.
Согласования — это половина проекта, особенно когда регламенты для ИИ‑сервисов еще не написаны.
Прототип, которым пользуются, — это обязательство. Как только люди встроили инструмент в работу, «поиграли и хватит» — больше не вариант.
Сопротивление — это сигнал. Оно показывает, где вы забыли позвать эксперта в разговор. Плюс, это возможность познакомиться с разными процессами в компании.
Продукт растет там, где о нем узнают. Наша аудитория расширилась, но самый большой сегмент рабочих встреч сам по себе не превратился в стихийное внедрение — это постоянная работа.
Если вы прямо сейчас внедряете ИИ‑инструменты, проверьте, кто писал требования, есть ли они, существует ли процесс согласования ИИ‑инструментов, действительно ли за столом сидят те, чью работу вы собираетесь менять?
Что дальше: учимся считать
Сейчас у нас несколько сервисов на проде и начался следующий, увлекательный этап под названием: «а реально ли это стоит тех денег, которые мы тратим?»
Это отдельная большая тема. Начали с метрик и сразу выяснили, что очевидные не всегда работают.
В транскрибаторе из числа обработанных файлов, мы хотим выделять долю тех, которые реально дошли до анализа, повлияли на задачи и выявили проблемы, которые могли оставаться неочевидными.
Дальше вопрос стоимости. У внутреннего сервиса очень легко получается красивая картинка, где для пользователя все бесплатно, а счет за токены приходит куда‑то в общий котел, и никто не соотносит одно с другим.
Сейчас мы учимся видеть цену каждого сценария использования отдельно: сколько стоит расшифровка часового интервью, сколько стоит краткое содержание планерки и проч.
И еще стараемся не забывать, что есть задачи, где дешевле «сделать руками». Гонять большую модель ради саммари очередного созвона — это чистая победа технологии над здравым смыслом.
Мы начали честно размечать, где ИИ выигрывает и экономит время, а где проигрывает. Мы даже провели внутренний семинар по подбору верной модели под задачу, чтобы не использовать самую мощную по умолчанию.
Мне нравится такое развитие, мы вернулись к очень приземленному продуктовому вопросу, где окупается именно автоматизация.
Похоже, следующий материал будет про то, где и как мы ошибались и что получилось по метрикам.
