Принципы дизайна ИИ-продуктов (UX для ИИ-функций)

User Needs + Defining Success. Прежде чем добавлять ИИ в продукт, честно проверь: даёт ли он здесь уникальную ценность, которую нельзя получить проще, без ИИ. Метрики успеха при этом ориентируй на пользователя (сэкономленное время, решённая задача), а не только на техническую точность модели.

Fundamentals. Три вопроса к любой ИИ-функции: зачем она пользователю (purpose), что она реально улучшает (value) и готов ли пользователь ей довериться (trust). Плюс мысль, что отношения с ИИ-продуктом строятся постепенно, как с человеком.

Basics. Ликбез для нетехнических людей: что такое ИИ, машинное обучение и данные — простыми словами, без формул. Нужен, чтобы говорить с инженерами на одном языке.

Восемь способностей ИИ из набора CMU: оценить, прогнозировать, сравнить, обнаружить, распознать, открыть, сгенерировать, действовать. Метод «сватовства» идёт от способности к задачам, а не наоборот. Шаблон концепта: потребность, способность («о чём система рассуждает?»), данные, действие.

Концепты оцениваются по двум матрицам: влияние × усилия и экспертиза задачи × качество ИИ. Правило набора: искать случаи, где среднее качество ИИ уже создаёт ценность. Это ответ на вопрос PAIR «нужен ли здесь ИИ» в виде упражнения, а не принципа.

Mental Models. Пользователи переносят ожидания от привычного софта на ИИ-продукты и часто ошибаются в этих ожиданиях. Задача дизайна — с первого экрана явно объяснить, что система умеет, чего не умеет и как с ней взаимодействовать. Оставлять это на самостоятельное угадывание нельзя.

Conversation. Раздел именно про диалоговые интерфейсы (чат-ботов). Как планировать сценарии диалога, что показывать, когда бот не понял вопрос (fallback-реплики), и как задать тон голоса бота, чтобы он не звучал ни слишком роботизированно, ни ложно по-человечески.

18 правил Microsoft HAX проверены с практиками на реальных продуктах. Их ценность в группировке по фазам:

На вопрос 2 отвечают первые две фазы, G1–G6.

Три уровня объяснимости Google описаны в статье Келли и Вудрафф в ACM Interactions. Рубрика перечисляет 22 пункта, которые полезно объяснить пользователю, и раскладывает их по уровням. Общий уровень: роль ИИ в продукте, цель, бизнес-модель, меры безопасности. Уровень функции: когда ИИ активен, какие есть настройки, ограничения, какие данные используются. Уровень решения: как принято конкретное решение, уверенность, как исправить или оспорить.

Объяснения размещаются по моментам: онбординг, первое использование, ошибка, отсутствие данных, оспаривание, итог решения.

Explainability + Trust. Откалибруй доверие пользователя. Не позволяй интерфейсу выглядеть увереннее, чем система есть на самом деле. Показывай уровень уверенности там, где ошибка дорого стоит пользователю.

Errors + Graceful Failure. Заранее спроектируй, что происходит, когда ИИ ошибается: как выглядит сообщение об ошибке, какие есть альтернативные действия и как не потерять доверие пользователя после сбоя.

Сюда же относятся правила HAX G7–G11 из таблицы выше и правила Apple HIG для генеративного контента. Apple просит не создавать впечатления, что контент написан человеком; заранее обозначать границы; не автоматизировать разрушительные действия и просить подтверждение перед значимыми; ставить рядом с результатом кнопки Изменить, Отменить, Повторить, Настроить. Вместо спиннера — конкретный текст прогресса («Собираю ключевые темы из ваших заметок»), альтернативные варианты, путь без ИИ, добровольная оценка.

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

Feedback + Control. У пользователя должен быть понятный способ поправить систему, отклонить её предложение или объяснить, что она ошиблась. Так он не теряет ощущение контроля над своими действиями.

Data Collection + Evaluation. Качество данных, на которых обучается или работает система, напрямую определяет качество продукта. Участвуй в разговоре о том, какие данные собираются и как оценивается качество работы модели. Это не только инженерный вопрос.

Ethics. Пять принципов, которые держи как чек-лист при проектировании любой ИИ-функции:

• Accountability (подотчётность) — всегда должно быть понятно, кто несёт ответственность за решение, принятое с помощью ИИ, и как это решение можно оспорить;
• Value alignment (соответствие ценностям) — поведение системы должно соответствовать ценностям и ожиданиям пользователя и организации, а не только техническим метрикам;
• Explainability (объяснимость) — пользователь должен иметь возможность понять, почему система выдала именно такой результат, хотя бы на базовом уровне;
• Fairness (справедливость) — система не должна систематически хуже работать или дискриминировать по отношению к отдельным группам пользователей;
• User data rights (права пользователя на данные) — пользователь должен понимать, какие его данные используются, и иметь возможность контролировать это.

Team Essentials. IBM переносит дизайн-мышление на ИИ-команды: общий язык для технических и нетехнических ролей и пять фокусов — intent, data, understanding, reasoning, knowledge. Практический вывод для дизайнера: место за столом с тем, кто отвечает за данные и за этику, нужно с первого дня, а не на этапе полировки. Эта тема перекликается с темой «ИИ-лидерство».

Сюда относятся правила HAX G12–G18 и три инструмента набора HAX. Workbook: на этапе требований команда выбирает правила и оценивает, что нужно от UI, модели, данных и инженеров. Design Library: паттерны и примеры по каждому правилу. Playbook: по нескольким вопросам о продукте с естественным языком генерирует вероятные сценарии сбоев. Team Essentials и Workbook отвечают на вторую половину вопроса: кого звать на этапе постановки задачи.

Семь граней UX Honeycomb Морвилла (2004): useful, usable, desirable, findable, accessible, credible, valuable. Это рамка для любого продукта. Как рубрика для ИИ-функций соты нигде не опубликованы, здесь это наша адаптация.

Грани credible и usable получают вопросы из HAX. Видно ли, что умеет система и насколько хорошо (G1, G2)? Можно ли вызвать, отклонить и поправить результат (G7–G9)? Объяснено ли, почему система сделала то, что сделала (G11)? Грань valuable связывает тему с метриками в теме «Метрики и evals ИИ-функции». Соты удобны как первый проход по чужой ИИ-функции в задании, до шести глав PAIR.

Как функция «Сплита» отвечает на каждый вопрос и какое правило за этим стоит (пример условный):

ИИ в продукте вредит в четырёх случаях. Функция добавлена ради слова «ИИ» в релизе. Интерфейс выглядит увереннее, чем модель. У ошибки нет пути назад. За решение модели никто в команде не отвечает.

Как принципы превращаются в конкретные элементы экрана — следующая тема.

Проверь мой сценарий ИИ-фичи на соответствие принципу "Mental Models" из PAIR: достаточно ли понятно пользователю уже на первом экране, что умеет и не умеет эта функция?

Спроектируй состояние ошибки для случая, когда ИИ-ассистент не смог ответить на вопрос — по принципу "graceful failure": что показать пользователю, какие есть альтернативные действия

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

Оцени этот экран ИИ-функции по пяти принципам этики IBM (accountability, value alignment, explainability, fairness, user data rights) — по каждому пункту скажи, выполняется он или нет, и почему

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

Пройди эту ИИ-функцию [описать] по трём вопросам из Fundamentals IBM: зачем она пользователю (purpose), что она реально улучшает (value) и почему пользователь должен ей довериться (trust). Где ответ слабый — там риск

Разложи проект ИИ-функции [описать] по пяти фокусам Team Essentials IBM — intent, data, understanding, reasoning, knowledge — и для каждого скажи, кого из команды позвать ещё на этапе постановки задачи

Пройди ИИ-функцию [описать] по 18 правилам HAX по фазам: в начале (G1–G2), во время работы (G3–G6), когда ИИ ошибся (G7–G11), со временем (G12–G18). По каждому правилу: выполняется, не выполняется или не применимо, с указанием элемента экрана. Для правил G7–G11 отдельно опиши, что видит пользователь, когда результат неверный

Вот описание ИИ-функции и её экраны. Разложи, что пользователю нужно объяснить, по трём уровням Google Explainability: общий, функции, решения. Для каждого пункта укажи момент показа: онбординг, первое использование, ошибка, нет данных, оспаривание, итог. Пометь пункты, которых в текущем интерфейсе нет

У нас есть данные [описать] и задача пользователей [описать]. Пройди восемь способностей ИИ из набора CMU — оценить, прогнозировать, сравнить, обнаружить, распознать, открыть, сгенерировать, действовать — и для каждой предложи одну функцию по шаблону: потребность, о чём система рассуждает, какие данные, какое действие. Затем оцени каждую по двум матрицам: влияние × усилия и экспертиза задачи × ожидаемое качество ИИ. Выдели случаи, где среднее качество модели уже создаёт ценность

Проверь функцию [описать] по семи граням UX Honeycomb. По каждой грани — оценка 1–5 с доказательством на экранах [приложены]. Useful: результат ИИ помогает задаче лучше, чем путь без ИИ? Usable: можно вызвать, отклонить и поправить? Desirable: функция не навязчива и в духе продукта? Findable: функцию и её результаты можно найти позже? Accessible: сгенерированный контент и состояния загрузки работают с ассистивными технологиями? Credible: показаны ограничения, уверенность и источники, ИИ раскрыт? Valuable: какую бизнес-метрику двигает? В конце — три самые низкие оценки и по одному исправлению