AI UX manager
Как приход AI поменял подходы к формированию UX
Содержание:
Кто такой AI UX Manager и чем он отличается от обычного
Раньше дизайнер проектировал предсказуемые вещи.
Нажал кнопку - получил известный результат. Всё шло по рельсам.
Это не просто старый подход, это целая эпоха, которая сейчас заканчивается.
Теперь всё иначе.
Дизайнер работает с искусственным интеллектом. А AI - это непредсказуемая, вероятностная система. Она может удивить, ошибиться или выдать гениальный результат. И это меняет абсолютно всё в работе.
Вот простой пример:
Обычный UX менеджер проектирует перевод денег в приложении.
Это прямой коридор: вбил сумму, нажал "отправить", готово.
Путь пользователя выверен до миллиметра.
AI UX менеджер проектирует для того же банка чат-бота.
Пользователь пишет ему: «скинь брату косарь».
Задача - не просто понять запрос. Нужно предусмотреть, что AI может переспросить, предложить варианты или вообще не понять. Нужно спроектировать сам диалог, а не просто кнопки.
Меняется сама суть работы.
Раньше всё начиналось с цели юзера. Сейчас старт другой - нужно понять сам AI. На что он способен? Где его потолок?
Поэтому работа AI UX менеджера - это постоянный диалог с машиной и её создателями.
Он не просто рисует экраны.
Он помогает подбирать данные для обучения.
Продумывает, что делать, если AI зациклится или начнёт нести бред.
Отсюда и главная задача.
Классический UX убивает неопределенность. AI UX, наоборот, приручает неопределенность. Его работа - сделать так, чтобы юзер не боялся ошибок AI, а мог с ними работать.
Ответственность тоже другая.
Обычный UX отвечает за удобство и деньги.
У AI UX менеджера всё серьезнее. На нём висят этика и доверие. Он должен думать об алгоритмической предвзятости - это когда AI, обученный на кривых данных, начинает выдавать кривые результаты.
Например, отказывать в кредите по странным признакам (Apple card так попали на большие репутационные потери из-за предвзятости кредитного скоринга). Задача менеджера - предвидеть это. В этом и есть конечная цель.
У классических приложений это максимальное удобство.
У AI UX - калибровка доверия.
Это не абстракция.
Калибровка доверия - это когда интерфейс сам подсказывает, насколько он уверен. Ответ подсвечен жёлтым, а рядом кнопка «проверить источник». Или AI прямо говорит: «Я не уверен, но предполагаю вот что…».
И это честно. Так и должно быть.
И главная задача AI UX - не просто сделать красиво, а выстроить эти честные отношения между человеком и машиной.
Нажал кнопку - получил известный результат. Всё шло по рельсам.
Это не просто старый подход, это целая эпоха, которая сейчас заканчивается.
Теперь всё иначе.
Дизайнер работает с искусственным интеллектом. А AI - это непредсказуемая, вероятностная система. Она может удивить, ошибиться или выдать гениальный результат. И это меняет абсолютно всё в работе.
Вот простой пример:
Обычный UX менеджер проектирует перевод денег в приложении.
Это прямой коридор: вбил сумму, нажал "отправить", готово.
Путь пользователя выверен до миллиметра.
AI UX менеджер проектирует для того же банка чат-бота.
Пользователь пишет ему: «скинь брату косарь».
Задача - не просто понять запрос. Нужно предусмотреть, что AI может переспросить, предложить варианты или вообще не понять. Нужно спроектировать сам диалог, а не просто кнопки.
Меняется сама суть работы.
Раньше всё начиналось с цели юзера. Сейчас старт другой - нужно понять сам AI. На что он способен? Где его потолок?
Поэтому работа AI UX менеджера - это постоянный диалог с машиной и её создателями.
Он не просто рисует экраны.
Он помогает подбирать данные для обучения.
Продумывает, что делать, если AI зациклится или начнёт нести бред.
Отсюда и главная задача.
Классический UX убивает неопределенность. AI UX, наоборот, приручает неопределенность. Его работа - сделать так, чтобы юзер не боялся ошибок AI, а мог с ними работать.
Ответственность тоже другая.
Обычный UX отвечает за удобство и деньги.
У AI UX менеджера всё серьезнее. На нём висят этика и доверие. Он должен думать об алгоритмической предвзятости - это когда AI, обученный на кривых данных, начинает выдавать кривые результаты.
Например, отказывать в кредите по странным признакам (Apple card так попали на большие репутационные потери из-за предвзятости кредитного скоринга). Задача менеджера - предвидеть это. В этом и есть конечная цель.
У классических приложений это максимальное удобство.
У AI UX - калибровка доверия.
Это не абстракция.
Калибровка доверия - это когда интерфейс сам подсказывает, насколько он уверен. Ответ подсвечен жёлтым, а рядом кнопка «проверить источник». Или AI прямо говорит: «Я не уверен, но предполагаю вот что…».
И это честно. Так и должно быть.
И главная задача AI UX - не просто сделать красиво, а выстроить эти честные отношения между человеком и машиной.
Ключевые компетенции
Хотите в AI UX - придется качать новые скиллы. Старого багажа уже не хватит. Это не просто добавить строчку в резюме, это реально новый набор компетенций.
Сначала - база. Без неё никуда.
Фундамент классического UX - это святое. Исследования пользователей, прототипы, эмпатия, умение общаться - всё это остаётся. Вы всё ещё работаете для человека, а не для машины. Этот фундамент это основа для профессии. По сути, Вы не выкидываете старые инструменты - вы просто готовите верстак для новых.
Вся эта часть собрана здесь
AI-грамотность.
Кодить не надо. Но надо понимать, как эта магия работает под капотом. Что такое "уровень уверенности модели"? Это её внутренний голос, который говорит: "в этом ответе я уверен на 90%, а в этом - только на 40%".
Ваша работа - сделать так, чтобы интерфейс передал этот голос пользователю. Нужно говорить с ML-инженерами на одном языке, чтобы не просить от модели невозможного. В итоге этот навык делает Вас переводчиком с машинного на человеческий. Без этого моста вся конструкция развалится.
Проектирование для хаоса.
Это когда Вы не скрываете косяки AI, а честно показываете их. Ваш дизайн должен отвечать на вопросы: "Почему AI так решил?", "Откуда эта информация?". Это и есть Explainable AI (XAI).
Вы добавляете в интерфейс ссылки на источники, подсказки, индикаторы уверенности. Ваша цель - управлять ожиданиями, чтобы пользователь не думал, что говорит с всезнающим оракулом. Честность в этом вопросе невероятно важна, здесь как у врачей "не навреди".
И наконец - этика. Самое сложное.
AI UX-менеджер - это совесть продукта. Он должен чуять предвзятость. Если модель обучали на данных про успешных белых мужчин, она будет хуже работать для всех остальных. Это может стоить людям денег, здоровья или возможностей.
Тут важно помнить, что если в нейронку поступает мусор из данных на входе, то и в результате будет мусор.
Поэтому придется задавать команде неудобные вопросы про данные и не дать выкатить на рынок продукт, который вредит.
Итого:
Роль UX-дизайнера/менеджера в мире AI - это уже не про то, как красиво расставить кнопки.
Это роль стратега, который видит риски. Роль дипломата, который договаривается с машиной. И роль гида, который ведёт пользователя за руку через новый, дикий и непонятный мир. И в этом мире старые карты больше не работают.
Сначала - база. Без неё никуда.
Фундамент классического UX - это святое. Исследования пользователей, прототипы, эмпатия, умение общаться - всё это остаётся. Вы всё ещё работаете для человека, а не для машины. Этот фундамент это основа для профессии. По сути, Вы не выкидываете старые инструменты - вы просто готовите верстак для новых.
Вся эта часть собрана здесь
AI-грамотность.
Кодить не надо. Но надо понимать, как эта магия работает под капотом. Что такое "уровень уверенности модели"? Это её внутренний голос, который говорит: "в этом ответе я уверен на 90%, а в этом - только на 40%".
Ваша работа - сделать так, чтобы интерфейс передал этот голос пользователю. Нужно говорить с ML-инженерами на одном языке, чтобы не просить от модели невозможного. В итоге этот навык делает Вас переводчиком с машинного на человеческий. Без этого моста вся конструкция развалится.
Проектирование для хаоса.
Это когда Вы не скрываете косяки AI, а честно показываете их. Ваш дизайн должен отвечать на вопросы: "Почему AI так решил?", "Откуда эта информация?". Это и есть Explainable AI (XAI).
Вы добавляете в интерфейс ссылки на источники, подсказки, индикаторы уверенности. Ваша цель - управлять ожиданиями, чтобы пользователь не думал, что говорит с всезнающим оракулом. Честность в этом вопросе невероятно важна, здесь как у врачей "не навреди".
И наконец - этика. Самое сложное.
AI UX-менеджер - это совесть продукта. Он должен чуять предвзятость. Если модель обучали на данных про успешных белых мужчин, она будет хуже работать для всех остальных. Это может стоить людям денег, здоровья или возможностей.
Тут важно помнить, что если в нейронку поступает мусор из данных на входе, то и в результате будет мусор.
Поэтому придется задавать команде неудобные вопросы про данные и не дать выкатить на рынок продукт, который вредит.
Итого:
Роль UX-дизайнера/менеджера в мире AI - это уже не про то, как красиво расставить кнопки.
Это роль стратега, который видит риски. Роль дипломата, который договаривается с машиной. И роль гида, который ведёт пользователя за руку через новый, дикий и непонятный мир. И в этом мире старые карты больше не работают.
Процесс проектирования UX для AI-продукта
Здесь нет заранее известных путей, потому что AI по своей природе непредсказуем.
Это скорее свободный поиск, чем движение по маршруту.
Но все же есть основные принципы, с которых стоило бы начать.
Ваша работа начинается не с проектирования интерфейсов, а с общения с разработчиками. Ваша задача - понять, на каких данных обучали модель.
Команда Google при разработке функции умных ответов (Smart Reply) в Gmail столкнулась с проблемой.
Изначально модель, обученная на огромном массиве писем, предлагала в качестве ответа на некоторые сообщения фразу «Я тебя люблю». С точки зрения статистики это был логичный ответ, но в рабочем контексте катастрофа.
UX-исследователям пришлось работать с инженерами, чтобы понять, почему это происходит, и вручную задать ограничения, исключающие подобные ответы.
Это было на заре внедрения AI в массовые продукты, но все же показывает насколько важен тренировочный набор данных.
Это скорее свободный поиск, чем движение по маршруту.
Но все же есть основные принципы, с которых стоило бы начать.
Ваша работа начинается не с проектирования интерфейсов, а с общения с разработчиками. Ваша задача - понять, на каких данных обучали модель.
Команда Google при разработке функции умных ответов (Smart Reply) в Gmail столкнулась с проблемой.
Изначально модель, обученная на огромном массиве писем, предлагала в качестве ответа на некоторые сообщения фразу «Я тебя люблю». С точки зрения статистики это был логичный ответ, но в рабочем контексте катастрофа.
UX-исследователям пришлось работать с инженерами, чтобы понять, почему это происходит, и вручную задать ограничения, исключающие подобные ответы.
Это было на заре внедрения AI в массовые продукты, но все же показывает насколько важен тренировочный набор данных.
Важно определить роль AI. Это помощник, партнер или автопилот?
Разбираем типы:
Помощник:
Siri или Google Assistant.
Они не начинают диалог первыми и не предлагают ничего без запроса. Их задача четко выполнить вашу команду: «Поставь будильник на 7 утра» или «Какая погода на улице?».
Разбираем типы:
Помощник:
Siri или Google Assistant.
Они не начинают диалог первыми и не предлагают ничего без запроса. Их задача четко выполнить вашу команду: «Поставь будильник на 7 утра» или «Какая погода на улице?».
Вот почему нейронка должна хорошо понимать контекст вопроса:)
Партнер:
GitHub Copilot.
Он не пишет код вместо вас.
Но предлагает варианты дополнения во время написания кода.
Решение все еще за вами, но получаете постоянную поддержку. Но тут еще важно понимать какой финальный результат мы ожидаем.
GitHub Copilot.
Он не пишет код вместо вас.
Но предлагает варианты дополнения во время написания кода.
Решение все еще за вами, но получаете постоянную поддержку. Но тут еще важно понимать какой финальный результат мы ожидаем.
Автопилот:
Лента рекомендаций TikTok.
Алгоритм не спрашивает, что вы хотите посмотреть. Он анализирует ваше поведение (лайки, время просмотра, репосты) и самостоятельно формирует бесконечную ленту. Если попытаться объединить несколько других алгоритмов в систему и автоматизировать процесс перехода между ними, то можно собрать агента.
Лента рекомендаций TikTok.
Алгоритм не спрашивает, что вы хотите посмотреть. Он анализирует ваше поведение (лайки, время просмотра, репосты) и самостоятельно формирует бесконечную ленту. Если попытаться объединить несколько других алгоритмов в систему и автоматизировать процесс перехода между ними, то можно собрать агента.
Нужна схема вероятностей.
Обычная карта пути клиента здесь не подойдёт. Вместо неё нужно создавать схему вероятностей, продумывая, как система будет исправлять ошибки.
Проектирование любого современного чат-бота в банковском приложении или сервисе доставки опирается на принципы починки диалога (Conversation Repair).
Вместо того чтобы выводить «Что то пошло не так», система должна предлагать пути решения.
Исследования можно проводить по методу Волшебник страны Оз
Все просто: человек тайно имитирует ответы AI. Причем так работает не только в скамерских AI стартапах но и вполне в себе в корпорациях ("умные" магазины от Amazon)
Этот метод также был ключевым при создании Google Duplex.
AI, который может звонить в рестораны для бронирования столика. Прежде чем доверить это реальной нейросети, команда Google использовала живых людей, которые слушали запросы пользователей и в реальном времени говорили от имени AI, чтобы отладить все возможные сценарии диалога. Заодно и датасет реальных пользовательских запросов насобирали.
Обычная карта пути клиента здесь не подойдёт. Вместо неё нужно создавать схему вероятностей, продумывая, как система будет исправлять ошибки.
Проектирование любого современного чат-бота в банковском приложении или сервисе доставки опирается на принципы починки диалога (Conversation Repair).
Вместо того чтобы выводить «Что то пошло не так», система должна предлагать пути решения.
Исследования можно проводить по методу Волшебник страны Оз
Все просто: человек тайно имитирует ответы AI. Причем так работает не только в скамерских AI стартапах но и вполне в себе в корпорациях ("умные" магазины от Amazon)
Этот метод также был ключевым при создании Google Duplex.
AI, который может звонить в рестораны для бронирования столика. Прежде чем доверить это реальной нейросети, команда Google использовала живых людей, которые слушали запросы пользователей и в реальном времени говорили от имени AI, чтобы отладить все возможные сценарии диалога. Заодно и датасет реальных пользовательских запросов насобирали.
Примеры из реального мира
Основные сценарии где мы уже давно встречаемся с AI алгоритмами и даже не замечаем это - рекомендательные движки.
Spotify - Персонализация музыки
AI DJ отличный пример.
Она не просто подбирает треки на основе истории прослушивания, но и объясняет свой выбор с помощью голосовых комментариев, тем самым создает ощущение персонализированного радио.
Spotify - Персонализация музыки
AI DJ отличный пример.
Она не просто подбирает треки на основе истории прослушивания, но и объясняет свой выбор с помощью голосовых комментариев, тем самым создает ощущение персонализированного радио.
Duolingo - Адаптивное обучение
Платформа использует AI для анализа паттернов обучения пользователя и подкидывает индивидуальные уроки.
Если пользователь делает ошибки в определенной теме, ИИ предложит больше упражнений именно на нее, и дает обратную связь в моменте.
Человек создает только основу в виде силлабуса, а вся персонализация в основном перекладывается на AI
Платформа использует AI для анализа паттернов обучения пользователя и подкидывает индивидуальные уроки.
Если пользователь делает ошибки в определенной теме, ИИ предложит больше упражнений именно на нее, и дает обратную связь в моменте.
Человек создает только основу в виде силлабуса, а вся персонализация в основном перекладывается на AI
Sephora - Виртуальная примерка
С помощью AI и computer vision приложение решает проблему "примерки" макияжа. А в продажах декоративной косметики это супер важно. Хотя это и попытка воспроизвести офлайн клиентский опыт в онлайне, но все же конверсию в продажу это поднимает
С помощью AI и computer vision приложение решает проблему "примерки" макияжа. А в продажах декоративной косметики это супер важно. Хотя это и попытка воспроизвести офлайн клиентский опыт в онлайне, но все же конверсию в продажу это поднимает
Модели коллаборации и структура команд
Подход из продуктового трио работает и в AI. Только с поправкой на специфику.
По ролям это три человека: Продакт, UX менеджер/дизайнер и ML-инженер. Если они не сидят за одним столом (реальным или виртуальным), ничего не взлетит.
В Spotify при разработке рекомендательных систем, вроде знаменитого плейлиста «Открытия недели», команда (squad) формируется именно по такому принципу.
Продакт определяет, как фича повлияет на удержание пользователей. UX-исследователь изучает, почему люди пропускают треки. А ML-инженер на основе этих данных тюнит алгоритм. Они не передают задачи друг другу - они решают их вместе на общей встрече.
Как собрать команду: Спецназ или партизаны?
Есть два основных пути, и у каждого свои плюсы и минусы.
Централизованный спецназ:
Одна крутая ML-команда на всю компанию. Они собирают всю экспертизу по AI у себя. Минус: к ним вечная очередь, и они могут быть далеки от реальных проблем пользователей.
Автономные отряды (Agile Pods): В каждой продуктовой команде есть свой ML-специалист. Они ближе к земле и быстрее работают.
Минус: могут по незнанию изобретать велосипеды.
Большинство гигантов, вроде Google или Microsoft, используют гибридную модель. Есть центральный мозг (исследовательские лаборатории Google AI или Microsoft Research), и есть «руки» - встроенные специалисты в командах Google Photos, YouTube или Xbox. Но пытаться повторить их модель один-в-один будет дорого конечно.
Общий язык: Как подружить дизайнера и инженера
Чтобы эти люди не говорили на разных языках, им нужны общие шпаргалки. Slack и Jira - это само собой. Но есть и специфические инструменты.
Google для этого придумали Model Cards (паспорта моделей). Это короткий документ, который человеческим языком описывает AI-модель: на каких данных её учили, где она сильна, а где может ошибаться, и есть ли у неё предрассудки.
Дизайнер читает такую карточку и сразу понимает, где в интерфейсе нужно подстелить соломки, например, добавить кнопку "сообщить об ошибке" или объяснить пользователю, почему результат именно такой.
Этика: Не создаём ли мы монстра?
Этот вопрос не для отдельного скучного комитета. Он должен звучать на каждом общем созвоне.
Это тот самый момент, когда возможности продукта настолько широки, что придется подключать регуляторику, чтобы не устроить апокалипсис.
В Microsoft действуют "Принципы ответственного AI", где ключевую роль играют справедливость и подотчётность. Это не просто красивые слова на сайте. Любая команда, использующая AI, обязана заполнить специальный опросник, где должна проанализировать, не навредит ли их фича какой-либо группе людей.
Если дизайнер на этапе прототипа видит, что система распознавания лиц хуже работает на женщинах или людях с тёмным цветом кожи, он обязан поднять тревогу. Промолчать значит стать соучастником.
И очень хочется надеяться что они эти принципы соблюдают.
Потому что если обойти защиту AI модели, можно докопаться до знаний, которые в плохих руках могут реально могут повлиять на жизни людей.
По ролям это три человека: Продакт, UX менеджер/дизайнер и ML-инженер. Если они не сидят за одним столом (реальным или виртуальным), ничего не взлетит.
В Spotify при разработке рекомендательных систем, вроде знаменитого плейлиста «Открытия недели», команда (squad) формируется именно по такому принципу.
Продакт определяет, как фича повлияет на удержание пользователей. UX-исследователь изучает, почему люди пропускают треки. А ML-инженер на основе этих данных тюнит алгоритм. Они не передают задачи друг другу - они решают их вместе на общей встрече.
Как собрать команду: Спецназ или партизаны?
Есть два основных пути, и у каждого свои плюсы и минусы.
Централизованный спецназ:
Одна крутая ML-команда на всю компанию. Они собирают всю экспертизу по AI у себя. Минус: к ним вечная очередь, и они могут быть далеки от реальных проблем пользователей.
Автономные отряды (Agile Pods): В каждой продуктовой команде есть свой ML-специалист. Они ближе к земле и быстрее работают.
Минус: могут по незнанию изобретать велосипеды.
Большинство гигантов, вроде Google или Microsoft, используют гибридную модель. Есть центральный мозг (исследовательские лаборатории Google AI или Microsoft Research), и есть «руки» - встроенные специалисты в командах Google Photos, YouTube или Xbox. Но пытаться повторить их модель один-в-один будет дорого конечно.
Общий язык: Как подружить дизайнера и инженера
Чтобы эти люди не говорили на разных языках, им нужны общие шпаргалки. Slack и Jira - это само собой. Но есть и специфические инструменты.
Google для этого придумали Model Cards (паспорта моделей). Это короткий документ, который человеческим языком описывает AI-модель: на каких данных её учили, где она сильна, а где может ошибаться, и есть ли у неё предрассудки.
Дизайнер читает такую карточку и сразу понимает, где в интерфейсе нужно подстелить соломки, например, добавить кнопку "сообщить об ошибке" или объяснить пользователю, почему результат именно такой.
Этика: Не создаём ли мы монстра?
Этот вопрос не для отдельного скучного комитета. Он должен звучать на каждом общем созвоне.
Это тот самый момент, когда возможности продукта настолько широки, что придется подключать регуляторику, чтобы не устроить апокалипсис.
В Microsoft действуют "Принципы ответственного AI", где ключевую роль играют справедливость и подотчётность. Это не просто красивые слова на сайте. Любая команда, использующая AI, обязана заполнить специальный опросник, где должна проанализировать, не навредит ли их фича какой-либо группе людей.
Если дизайнер на этапе прототипа видит, что система распознавания лиц хуже работает на женщинах или людях с тёмным цветом кожи, он обязан поднять тревогу. Промолчать значит стать соучастником.
И очень хочется надеяться что они эти принципы соблюдают.
Потому что если обойти защиту AI модели, можно докопаться до знаний, которые в плохих руках могут реально могут повлиять на жизни людей.
Продвинутое тестирование и метрики успеха
Стандартные метрики для AI-продуктов - это обман.
Они хорошо смотрятся в отчётах, но в реальной жизни всё ломается.
Слепо верить цифрам значит создавать продукт, который провалится при встрече с реальным пользователем.
A/B-тесты теперь другие.
Тесты с покраской кнопок здесь не сработают. Теперь вы сравниваете фундаментальные вещи.
Например сервис Grammarly фокусируется не на тесте интерфейса.
Они могут запустить тест, где 50% пользователей видят исправления от старой модели AI, а другие 50% от новой.
Затем они смотрят, предложения какой из моделей люди принимают чаще. Это и есть настоящий A/B-тест AI-продукта.
Бенчмарки часто врут.
Высокий балл в лабораторном тесте не гарантирует успеха. Модель может идеально отвечать на выверенные запросы, но полностью теряться, столкнувшись с живой речью.
Первые чат-боты для поддержки клиентов отлично проходили тесты на заранее написанных сценариях. Но в реальной жизни они сыпались от опечаток, сленга или просто неожиданных вопросов, заставляя пользователей в ярости искать номер телефона оператора.
Старых KPI тоже больше не хватает.
Коэффициент конверсии или время на сайте это лишь часть картины. В AI-продуктах нужно смотреть на новые, более глубокие показатели.
Успех задачи.
Добился ли пользователь своей цели? Например, для AI-планировщика путешествий ключевой вопрос: пользователь в итоге купил билеты по предложенному маршруту или ушёл искать дальше?
Доверие к системе.
Как часто люди принимают советы AI?
GitHub Copilot измеряет свой успех не по количеству предложенных строк кода, а по acceptance rate - проценту принятых разработчиками предложений. Это прямой показатель доверия.
Стоимость. Не разоряет ли вас новая функция? Умная модель может давать чуть более качественные ответы, но стоить в 10 раз дороже в вызовах API. Часто бизнес решает, что менее дорогая, пусть и не идеальная, модель гораздо выгоднее в долгосрочной перспективе.
Раньше с такими глубокими метриками приходилось сталкиваться когда реализовывали поиск внутри продукта. Достаточно нишевая история. Но сейчас этот подход применим практически ко всем AI продуктам.
Никогда не выкатывайте обновления на всех сразу.
Цена ошибки выросла. Если крупные компании и раньше тестировали новый функционал на очень ограниченном количестве людей (например в google в целом никакая фича технически не могла распространиться сразу на всех пользователей).
Теперь же этот подход стал еще более важным.
Если ваш продукт начнет генерировать вред, то это может стать катастрофой очень быстро.
Показательный пример это Microsoft Tay, бот, который научился плохому от пользователей твиттера.
Они хорошо смотрятся в отчётах, но в реальной жизни всё ломается.
Слепо верить цифрам значит создавать продукт, который провалится при встрече с реальным пользователем.
A/B-тесты теперь другие.
Тесты с покраской кнопок здесь не сработают. Теперь вы сравниваете фундаментальные вещи.
Например сервис Grammarly фокусируется не на тесте интерфейса.
Они могут запустить тест, где 50% пользователей видят исправления от старой модели AI, а другие 50% от новой.
Затем они смотрят, предложения какой из моделей люди принимают чаще. Это и есть настоящий A/B-тест AI-продукта.
Бенчмарки часто врут.
Высокий балл в лабораторном тесте не гарантирует успеха. Модель может идеально отвечать на выверенные запросы, но полностью теряться, столкнувшись с живой речью.
Первые чат-боты для поддержки клиентов отлично проходили тесты на заранее написанных сценариях. Но в реальной жизни они сыпались от опечаток, сленга или просто неожиданных вопросов, заставляя пользователей в ярости искать номер телефона оператора.
Старых KPI тоже больше не хватает.
Коэффициент конверсии или время на сайте это лишь часть картины. В AI-продуктах нужно смотреть на новые, более глубокие показатели.
Успех задачи.
Добился ли пользователь своей цели? Например, для AI-планировщика путешествий ключевой вопрос: пользователь в итоге купил билеты по предложенному маршруту или ушёл искать дальше?
Доверие к системе.
Как часто люди принимают советы AI?
GitHub Copilot измеряет свой успех не по количеству предложенных строк кода, а по acceptance rate - проценту принятых разработчиками предложений. Это прямой показатель доверия.
Стоимость. Не разоряет ли вас новая функция? Умная модель может давать чуть более качественные ответы, но стоить в 10 раз дороже в вызовах API. Часто бизнес решает, что менее дорогая, пусть и не идеальная, модель гораздо выгоднее в долгосрочной перспективе.
Раньше с такими глубокими метриками приходилось сталкиваться когда реализовывали поиск внутри продукта. Достаточно нишевая история. Но сейчас этот подход применим практически ко всем AI продуктам.
Никогда не выкатывайте обновления на всех сразу.
Цена ошибки выросла. Если крупные компании и раньше тестировали новый функционал на очень ограниченном количестве людей (например в google в целом никакая фича технически не могла распространиться сразу на всех пользователей).
Теперь же этот подход стал еще более важным.
Если ваш продукт начнет генерировать вред, то это может стать катастрофой очень быстро.
Показательный пример это Microsoft Tay, бот, который научился плохому от пользователей твиттера.
Как вам материалы?
Об авторе:
Еще материалы по теме продакт менеджмента: