Human-AI Interaction Designer — специалист на стыке UX-дизайна, продуктового мышления, исследований и базового понимания ИИ. Его задача — сделать взаимодействие с моделью, помощником или агентом предсказуемым для человека: объяснить возможности системы, не скрыть ограничения, дать пользователю контроль и продумать восстановление после ошибок.

Это не отдельная «магическая» профессия, для которой существует единый диплом или строгий список обязанностей. На практике такие задачи часто лежат в ролях Product Designer, UX Designer, Conversational Designer, AI Product Designer или дизайнера GenAI-продуктов. Поэтому разумный путь входа — не ждать вакансию с идеальным названием, а наращивать AI-специализацию поверх сильной UX-базы.

Чем на самом деле занимается Human-AI Interaction Designer

Обычный интерфейс нередко строится вокруг предсказуемых действий: пользователь нажал кнопку — система сохранила форму; выбрал фильтр — список обновился. В AI-продукте результат может зависеть от неоднозначного запроса, неполных данных, вероятностной модели, подключённых инструментов и заданных ограничений. Дизайнеру приходится проектировать не только «идеальный путь», но и диапазон вероятных исходов.

Например, пользователь просит корпоративного AI-помощника подготовить сводку по встречам за неделю. Дизайнер решает:

  • какие источники помощник имеет право использовать;
  • как показать, какие документы были учтены;
  • когда запросить уточнение, а когда предложить черновик;
  • как отметить предположение или недостаток данных;
  • можно ли пользователю отредактировать результат;
  • какие действия агент может выполнить сам, а какие требуют подтверждения;
  • что увидит человек, если модель не нашла информацию, выдала сомнительный ответ или не может выполнить задачу.

Именно здесь профессия отличается от роли, в которой дизайнер только оформляет чат-окно. Ключевой объект проектирования — поведение системы и распределение контроля между человеком и ИИ.

Microsoft в рекомендациях Human-AI Interaction предлагает рассматривать опыт на всех этапах: при первом знакомстве, во время работы, при ошибке системы и в длительном использовании. В частности, пользователю нужно ясно сообщать, что система умеет делать, а не создавать впечатление универсального «эксперта на всё». (microsoft.com)

Типичная рабочая задача

Представьте сервис для отдела продаж. Агент может прочитать карточку клиента, собрать историю переписки и подготовить черновик письма.

Плохое решение: кнопка «Отправить с ИИ», после которой письмо сразу уходит клиенту.

Более зрелое решение:

  1. Пользователь выбирает цель письма и видит, какие данные будут использованы.
  2. Система создаёт редактируемый черновик, а не отправляет сообщение самостоятельно.
  3. Рядом видны опорные факты: этап сделки, последние договорённости, дата следующего контакта.
  4. Если данных недостаточно, помощник прямо сообщает об этом и просит уточнение.
  5. Отправка остаётся отдельным подтверждаемым действием человека.
  6. После действия можно оценить результат или сообщить об ошибке.

Такой сценарий одновременно затрагивает UX, доверие, приватность, бизнес-логику, тексты интерфейса и технические ограничения. Для чувствительных, необратимых или высокорисковых действий особенно важен человеческий контроль: в руководстве OpenAI по агентам человеческое вмешательство названо критическим механизмом на ранних этапах внедрения и для операций с существенными последствиями. (openai.com)

Интерфейс AI-помощника с черновиком письма, источниками данных и ручным подтверждением отправки.
Реальная задача дизайнера — определить, какие данные использует помощник, что пользователь может проверить и где должно остаться финальное решение.

Подходит ли вам это направление

Профессия подойдёт не каждому человеку, которому просто нравится общаться с чат-ботами. Она ближе тем, кому интересно разбирать неопределённость и превращать её в ясный пользовательский опыт.

Вам будет легче, если вы:

  • уже делали UX/UI, продуктовый дизайн, сервис-дизайн, контент-дизайн или UX-исследования;
  • любите задавать уточняющие вопросы вместо того, чтобы сразу рисовать экраны;
  • спокойно относитесь к итерациям: один и тот же промпт, модель или сценарий придётся проверять много раз;
  • умеете объяснять сложное простым языком;
  • замечаете рискованные формулировки вроде «ИИ всё сделает сам»;
  • готовы разговаривать с разработчиками, аналитиками, ML-инженерами, юристами, службой поддержки и экспертами предметной области;
  • не хотите подменять исследование пользователей собственной интуицией.

Стоит осторожнее выбирать направление, если вам принципиально нужна работа с полностью фиксированным результатом. Генеративные модели могут давать разные ответы на близкие запросы, а продукты на их основе меняются быстрее, чем традиционные интерфейсные паттерны. Здесь ценится не способность угадать единственный «правильный экран», а умение поставить границы, предусмотреть сбои и проверить, помогают ли они человеку.

NIST отдельно отмечает, что роли, ответственность и степень надзора человека в системах «человек—ИИ» должны быть определены явно. Организациям также важно учитывать, что пользователи по-разному понимают ответы и объяснения AI-систем. (airc.nist.gov)

База навыков: что изучать и в каком порядке

Не пытайтесь за месяц стать одновременно ML-инженером, промпт-инженером, исследователем и дизайнером. Для входа важнее собрать связку из пяти компетенций.

1. Классический UX и продуктовый дизайн

Это фундамент, без которого AI-специализация будет поверхностной.

Освойте:

  • интервью и наблюдение за пользователями;
  • формулирование проблемы и гипотез;
  • customer journey map и task flow;
  • информационную архитектуру;
  • прототипирование в Figma;
  • usability-тесты;
  • работу с дизайн-системой;
  • понятные UX-тексты и состояния интерфейса.

AI не отменяет привычный вопрос: «Какую задачу человека мы решаем?» В People + AI Guidebook Google рекомендует начинать не с вопроса «Куда добавить ИИ?», а с поиска пересечения между потребностью пользователя и сильными сторонами технологии. Там же предлагается различать автоматизацию и усиление человека: не все важные или творческие задачи стоит полностью передавать системе. (pair.withgoogle.com)

2. Базовое понимание LLM и агентов

Дизайнеру не обязательно обучать модели, но нужно понимать их рабочие свойства и ограничения. Иначе нельзя реалистично проектировать интерфейс.

Разберитесь на практическом уровне:

  • что такое контекстное окно, системная инструкция и пользовательский запрос;
  • почему модель может уверенно ошибаться или придумывать факт;
  • чем генерация текста отличается от поиска по подключённой базе знаний;
  • что такое RAG, вызов инструментов и агентный сценарий;
  • почему модель не гарантирует одинаковый ответ на одинаковый запрос;
  • где появляются задержки, лимиты, ошибки доступа и стоимость выполнения;
  • что такое оценка качества ответов и почему одной метрики недостаточно.

Полезная привычка: каждый новый интерфейс проверяйте на трёх наборах запросов — типичных, неоднозначных и намеренно неудобных. Например: «Сделай отчёт», «Сделай отчёт по продажам за прошлый период» и «Сделай отчёт, но не используй данные клиентов и отправь его руководителю». Это быстро показывает, где нужны уточнения, ограничения и подтверждения.

3. Human-AI UX-паттерны

Это ядро специализации. Изучайте не отдельные «красивые промпты», а повторяющиеся принципы.

К ним относятся:

  • ожидания до запуска: что система умеет, какие входные данные нужны, что она не делает;
  • управляемость: настройки, выбор источников, редактирование, отмена и возврат к ручному режиму;
  • видимость процесса: понятное состояние ожидания, этапы действия агента, объяснение задержек;
  • работа с неопределённостью: запрос уточнений, маркировка предположений, демонстрация оснований ответа;
  • восстановление после ошибки: повтор, переформулирование, альтернативный путь, эскалация человеку;
  • обратная связь: возможность исправить результат и передать команде полезный сигнал;
  • калибровка доверия: не обещать больше, чем система реально способна сделать.

Google PAIR предупреждает, что чрезмерно «человеческая» подача AI может формировать неверные ожидания: человек начинает приписывать системе способности, которых у неё нет. Поэтому хорошее онбординг-сообщение говорит не о том, что «помощник всё знает», а о конкретных поддерживаемых задачах и границах. (pair.withgoogle.com)

4. Исследования и тестирование AI-сценариев

Прототип AI-функции нельзя проверить только вопросом «нравится ли вам этот экран?». Пользователь должен попытаться решить реальную задачу, увидеть несколько вариантов ответа и столкнуться с ошибкой.

На тесте наблюдайте:

  • понимает ли участник, что может запросить у системы;
  • замечает ли источники, ограничения и режимы;
  • способен ли исправить плохой результат;
  • доверяет ли ответу слишком сильно или, наоборот, не использует полезную функцию;
  • знает ли, что будет сделано автоматически;
  • может ли остановить или отменить действие агента.

Microsoft HAX Playbook предлагает заранее исследовать распространённые сбои AI-взаимодействия и моделировать их ещё до создания полнофункциональной системы. Это важная идея для портфолио: показывайте не только успешный результат, но и продуманный путь восстановления. (microsoft.com)

5. Доступность, приватность и риск

AI-интерфейс не освобождён от требований хорошего цифрового продукта. Если система выдаёт ошибку, пользователь должен получить ясное объяснение и понятный способ исправить ситуацию. W3C рекомендует давать обратную связь о результате действия, формулировать сообщения кратко и объяснять, как устранить проблему; эти принципы применимы и к AI-ответам, и к традиционным формам. (w3.org)

Приватность и риск особенно важны в сценариях с документами, персональными данными, финансами, медициной, наймом и юридическими вопросами. Дизайнер не заменяет юриста или специалиста по безопасности, но обязан поднять вопрос: какие данные видит модель, может ли пользователь это контролировать, что произойдёт при неверном ответе, нужен ли обязательный человеческий просмотр.

План входа на 12 месяцев

Срок не универсален. Если у вас уже есть сильный опыт в UX или продуктовой команде, переход может занять меньше времени. Если вы начинаете с нуля, разумнее сначала укрепить основы дизайна и исследований. Ниже — маршрут, рассчитанный на регулярную практику, а не на просмотр материалов «впрок».

Месяцы 1–3: закрепите UX-основу

  1. Выберите одну привычную цифровую задачу: запись к врачу, подбор вакансий, поддержка клиентов, работа с документами.
  2. Проведите 5–7 коротких интервью с потенциальными пользователями или разберите доступные отзывы и обращения в поддержку.
  3. Сформулируйте проблему без слова «ИИ». Например: «Менеджер тратит 25 минут, чтобы собрать историю клиента перед звонком».
  4. Сделайте обычный, не-AI сценарий решения задачи в Figma.
  5. Проведите хотя бы три usability-теста.

Цель этапа — научиться видеть задачу и контекст до выбора технологии.

Месяцы 4–6: добавьте AI как инструмент, а не украшение

Возьмите тот же кейс и спросите: где ИИ действительно уменьшит рутину или поможет с масштабом? Не добавляйте чат только потому, что он привычен.

Создайте карту сценария:

ЭтапВопрос дизайнераПример решения
До действияЧто пользователь ожидает от ИИ?Коротко описать поддерживаемые задачи и допустимые данные
В процессеЧто система делает сейчас?Показать обработку документов и возможность остановить задачу
РезультатМожно ли проверить и изменить ответ?Черновик с редактированием и ссылками на исходные записи
ОшибкаКак пользователь продолжит работу?Уточняющий вопрос, ручной ввод или передача специалисту
После использованияКак улучшить будущий опыт?Оценка полезности и исправление неверного фрагмента

Затем соберите кликабельный прототип. Для демонстрации не нужно писать приложение: можно подготовить несколько заранее созданных вариантов AI-ответов — удачный, неполный, ошибочный и небезопасный — и показать их участникам теста в нужный момент.

Месяцы 7–9: научитесь проектировать сбои

Это этап, на котором портфолио начинает отличаться от набора красивых чат-экранов.

Для каждого кейса составьте «матрицу отказов»:

  • пользователь сформулировал слишком общий запрос;
  • модель не нашла данных;
  • источник устарел или противоречив;
  • ответ не соответствует языку или тону пользователя;
  • агент хочет выполнить необратимое действие;
  • система задерживается;
  • пользователь не согласен с выводом;
  • запрос содержит данные, которые нельзя использовать.

Для каждого пункта спроектируйте реакцию интерфейса и объясните выбор. Не надо заявлять, что дизайн «решает проблему галлюцинаций»: интерфейс не способен гарантировать фактическую точность модели. Но он может снизить ущерб, помогая человеку проверять результат, ограничивая опасные действия и делая ограничения заметными.

Месяцы 10–12: соберите портфолио и начните искать смежные роли

Подготовьте 2–3 глубоких кейса, а не 10 одноэкранных концептов. Один кейс может быть учебным, второй — редизайном известного сценария, третий — небольшим проектом для некоммерческой организации, студенческой команды, знакомого эксперта или собственного пет-проекта. Важно честно пометить формат работы и не выдавать учебную концепцию за коммерческое внедрение.

Ищите роли шире, чем Human-AI Interaction Designer:

  • Product Designer / UX Designer в командах с AI-функциями;
  • Conversational Designer;
  • UX Researcher для AI-продуктов;
  • Content Designer / UX Writer для помощников и агентов;
  • AI Product Designer;
  • дизайнер внутренних инструментов, поиска, поддержки, аналитики и автоматизации.

На собеседовании полезнее показать, как вы мыслите о риске и проверке, чем демонстрировать длинный список промптов. Расскажите, какую пользовательскую проблему выбрали, какие неудачные ответы смоделировали, где оставили контроль человеку, что показали участникам теста и что поменяли по итогам.

Доска с картой AI-сценария, прототипом и карточками возможных ошибок системы.
В Human-AI UX проектируют не только успешный ответ, но и уточнения, задержки, ошибки, отмену действий и путь к ручному решению.

Каким должно быть портфолио

Сильный кейс отвечает на вопрос: «Сможет ли этот дизайнер помочь команде принять решения в условиях неопределённости?»

Структура одной работы:

  1. Контекст. Кто пользователь, какую задачу он решает, почему нынешний процесс неудобен.
  2. Роль ИИ. Что именно делает система и почему здесь нужен AI, а не стандартная автоматизация.
  3. Границы. Какие данные доступны, чего система не делает, где требуется подтверждение человека.
  4. Сценарий. Основной путь от запроса к проверяемому результату.
  5. Сбои. Минимум три проблемных состояния и решения для них.
  6. Прототип. Ключевые экраны или диалоговые шаги с пояснениями.
  7. Проверка. Как вы тестировали гипотезу, кто участвовал, что узнали.
  8. Следующий шаг. Какие метрики и вопросы команда проверила бы в реальном запуске.

Пример первого реалистичного кейса

Кейс: помощник для HR, который готовит черновик вакансии из брифа руководителя.

Не ограничивайтесь формой «Введите запрос — получите текст». Спроектируйте:

  • выбор языка, уровня позиции и обязательных требований;
  • уведомление о том, что текст требует проверки человеком;
  • отдельный блок с предположениями модели, если бриф неполный;
  • предупреждение при потенциально дискриминационных формулировках;
  • возможность посмотреть, какие пункты брифа вошли в текст;
  • редактирование до публикации;
  • кнопку «сообщить о проблеме» с выбором причины;
  • ручной путь: шаблон вакансии без генерации.

Такой кейс показывает и UX, и работу с текстом, и контроль качества, и понимание того, что AI не должен становиться непрозрачным автором решения.

Пользователь тестирует AI-инструмент с черновиком документа и возможностью проверить предположения или перейти к ручному шаблону.
Хороший AI-интерфейс не прячет неопределённость: он помогает человеку заметить предположения, исправить результат и продолжить работу без автоматизации.

Чек-лист перед откликами

Проверьте себя по пунктам ниже.

  • [ ] У меня есть хотя бы один кейс, где AI решает конкретную пользовательскую проблему, а не просто отвечает в чате.
  • [ ] В кейсе показаны основной путь, ограничения, ошибки и восстановление после них.
  • [ ] Я могу объяснить разницу между генерацией, поиском по базе знаний и агентным действием.
  • [ ] Я понимаю, какие действия нельзя отдавать агенту без подтверждения пользователя.
  • [ ] Я провёл хотя бы несколько тестов или честно описал, почему это пока не удалось и что проверил бы первым.
  • [ ] Я умею показать результат AI как черновик, рекомендацию или действие с разным уровнем контроля — в зависимости от риска.
  • [ ] Я знаю основы Figma, прототипирования, UX-исследований и UX-текстов.
  • [ ] Я не обещаю «полностью убрать ошибки модели» с помощью одного удачного интерфейса.
  • [ ] В портфолио явно отделены мои решения, допущения и результаты проверки.
  • [ ] В резюме и откликах я использую смежные названия ролей, а не рассчитываю только на редкую формулировку вакансии.

Честный вывод

Human-AI Interaction Designer — перспективная специализация для UX- и продуктовых дизайнеров, но не короткий путь к «работе в ИИ». Рынок названий и обязанностей ещё формируется, поэтому точная должность может встречаться нечасто. Устойчивее строить карьеру на базе продуктового дизайна, исследований и умения работать с командами, а Human-AI interaction использовать как заметную профессиональную специализацию.

Главный признак готовности к первой задаче — не сертификат и не коллекция промптов. Это способность разобрать реальный процесс, решить, нужен ли в нём AI, спроектировать понятный контроль, предусмотреть ошибку и проверить решение на людях. Если вам интересно делать технологию менее загадочной и более управляемой, направление стоит пробовать уже через небольшой, но тщательно проработанный кейс.

Источники и материалыПроверенные ссылки, использованные при подготовке