Проектирование интерфейса информационной системы в эпоху ИИ

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

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

Я часто замечаю на UX-исследованиях: пользователю не обязательно нужно знать, какая модель работает внутри. Но ему необходимо понимать, что система умеет, где она предполагает, где уверена, а где просто предлагает наиболее вероятный ответ. Это уже не только вопрос визуального оформления. Это вопрос доверия, ответственности и психологической безопасности сценария.

От детерминированного экрана к вероятностному поведению

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

ИИ устроен иначе. Его поведение имеет вероятностную природу. В традиционном программном обеспечении непоследовательный результат чаще всего воспринимается как ошибка или баг. Для модели машинного обучения вариативность может быть частью механики. Она не отменяет требований к качеству, но меняет саму логику взаимодействия: дизайнеру нужно показать не только результат, но и границы его надёжности.

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

В 2025 году ИИ-технологиями пользовались 66% пользователей по всему миру. При этом в информационных системах речь идёт не только о чат-интерфейсах и больших языковых моделях. Внутри продуктов могут работать рекуррентные и свёрточные нейросети, диффузионные модели и другие алгоритмы, которые вообще не выглядят для пользователя как собеседник. Поэтому проектирование UI/UX информационных систем под ИИ — это не задача по добавлению универсального чата в правый нижний угол экрана.

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

В интерфейсе с ИИ пользователь должен видеть не только ответ, но и степень своей власти над этим ответом.

У этой задачи есть несколько уровней.

• Понимание возможностей. Пользователь должен быстро распознать, что именно делает алгоритм: ищет, классифицирует, прогнозирует, генерирует, рекомендует или запускает действие.
• Контроль. Человек должен иметь возможность принять предложение, изменить его, отклонить или вернуться к исходным данным.
• Обратная связь. Система должна показывать, что она сейчас делает, чего ждёт и на каком этапе возникла неопределённость.
• Восстановление после ошибки. Даже хороший алгоритм ошибается. Вопрос в том, насколько легко заметить ошибку и исправить последствия.
• Стабильность сценария. ИИ может быть динамичным внутри, но пользовательский путь не должен превращаться в лотерею.

18 принципов Human-AI Interaction: не список правил, а маршрут отношений

В 2019 году Microsoft совместно с исследователями Вашингтонского университета сформулировала 18 руководящих принципов взаимодействия человека и ИИ. Они разделены на четыре этапа: первое знакомство с системой, непосредственное взаимодействие, момент ошибки и длительное использование.

Для проектировщика это полезно не как готовая инструкция к копированию, а как способ посмотреть на продукт во времени. Пользователь не встречается с алгоритмом один раз. Он сначала пытается понять его возможности, потом проверяет в деле, сталкивается с неожиданным результатом и постепенно формирует привычку — или решает больше не доверять системе.

Первый контакт: что умеет система и чего от неё ждать

Первый экран ИИ-функции не обязан превращаться в длинный учебник. Но он должен честно отвечать на несколько вопросов.

Что можно попросить? В каком формате лучше сформулировать задачу? Какие данные используются? Получит ли пользователь готовое действие или только рекомендацию? Есть ли ограничения по доступу, объёму информации и типам файлов?

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

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

При этом важно не создавать ложное ощущение универсальности. Если модель анализирует только документы из текущего раздела, это должно быть видно до отправки запроса. Если она не имеет права менять данные, пользователь должен понимать, что результатом будет предложение, а не выполненное действие.

Хорошее первое знакомство обычно включает:

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

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

В процессе работы: показывать логику, не перегружая деталями

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

В зависимости от сценария полезно показать:

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

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

В проектировании интерфейса информационной системы я предпочитаю разделять эти состояния визуально и поведенчески. Предложенный алгоритмом текст может находиться в режиме черновика. Изменённые поля — подсвечиваться до подтверждения. Автоматически найденные совпадения — сопровождаться ссылкой на исходную запись. Это не декоративные эффекты. Они помогают человеку удерживать в голове происхождение результата.

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

Когда система ошиблась: не прятать проблему за вежливой формулировкой

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

В такой ситуации фраза вроде «что-то пошло не так» оставляет пользователя один на один с проблемой. Ему приходится гадать: повторить запрос, изменить формулировку, проверить доступ, обратиться к администратору или вручную начать процесс заново.

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

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

2. Варианты следующего шага. Уточнить запрос, выбрать источник вручную, открыть исходные записи или продолжить без ИИ.

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

4. Возможность исправить результат. Нужны не только кнопки «принять» и «отклонить», но и точечное редактирование, обратная связь и понятная отмена.

5. Разделение ошибки модели и ошибки пользователя. Нельзя заставлять человека чувствовать, что он неправильно сформулировал задачу, если проблема возникла из-за ограничений самого сервиса.

Микрокопирайтинг здесь становится частью UX-архитектуры. Тёплый, ясный язык не скрывает ошибку, а помогает пройти её без лишнего стыда и раздражения. Пользователь не обязан быть специалистом по машинному обучению, чтобы понять, почему сценарий остановился.

Гибридный интерфейс: почему чат не заменяет дашборд

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

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

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

Гибридность хорошо работает, когда каждый элемент сохраняет свою сильную сторону. Чат помогает сформулировать намерение и быстро исследовать систему. Фильтры дают точность. Дашборд удерживает контекст. Таблица позволяет сравнивать и действовать над множеством объектов. Карточка показывает детали и историю изменений.

Контекст должен переходить между режимами

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

Контекст может проявляться в нескольких местах:

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

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

Этапы проектирования интерфейса ИС: что меняется в рабочем процессе

Базовая последовательность остаётся знакомой: исследование пользователей, информационная архитектура, прототипирование, UX-тестирование, визуальный стиль, UI-kit и передача в разработку. ИИ не отменяет этот процесс. Он делает некоторые вопросы более острыми и добавляет новые точки проверки.

Исследование: изучать не только задачи, но и отношение к автоматизации

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

Один и тот же человек может охотно доверить системе сортировку входящих писем, но не принять автоматическое изменение статуса договора. В этом нет противоречия. У задач разная цена ошибки, разная обратимость и разный уровень личной ответственности.

Я бы фиксировала в исследовании как минимум четыре характеристики сценария:

• Цена ошибки: что произойдёт, если алгоритм ошибётся.
• Обратимость: можно ли быстро отменить действие и восстановить исходное состояние.
• Проверяемость: способен ли пользователь самостоятельно сверить рекомендацию с первичными данными.
• Распределение ответственности: кто принимает финальное решение и кто отвечает за последствия.

Эти параметры помогают не превращать разговор об ИИ в спор о том, доверяют ему люди или нет. Доверие не бывает общим и постоянным. Оно складывается отдельно для каждой операции.

Информационная архитектура: разделять данные, рекомендации и действия

В традиционной системе граница между данными и интерфейсом уже важна. В AI-продукте к ней добавляется третий слой — интерпретация.

Пользователь должен отличать:

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

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

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

Прототипирование: моделировать неопределённость заранее

На этапе прототипа часто показывают только идеальный путь: запрос отправлен, правильный ответ получен, пользователь нажал подтверждение. Для ИИ этого недостаточно.

В прототип нужно включать как минимум несколько вариантов поведения:

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

Такие состояния помогают увидеть, где интерфейс оставляет человека без опоры. Иногда основной экран выглядит очень аккуратно, но вся забота о пользователе заканчивается в момент, когда модель не знает ответа.

UX-тестирование: проверять понимание, а не только скорость

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

После задания полезно спросить:

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

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

Где генеративные инструменты помогают дизайнеру, а где создают новую боль

Figma AI, Uizard, Midjourney и похожие инструменты уже применяются для автоматизации прототипирования, генерации вариантов интерфейсов и анализа внимания пользователей. Они действительно ускоряют рутинную часть работы.

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

Но генерация экрана не равна проектированию интерфейса. Модель может сделать аккуратный макет, в котором:

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

ИИ хорошо работает как партнёр по вариативности и черновой материал. Он хуже справляется с ответственностью за бизнес-логику, последствия действий и эмоциональную нагрузку пользователя. Эти задачи остаются за дизайнером и продуктовой командой.

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

Как встроить ИИ в дизайн-систему

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

В дизайн-системе стоит заранее описать:

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

Это уже не только набор компонентов. Дизайн-система начинает хранить правила поведения. Один и тот же компонент должен одинаково объяснять пользователю, что предложение создано алгоритмом, даже если в одном разделе это текст, а в другом — числовой прогноз.

Прозрачность без иллюзии полной объяснимости

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

Можно честно показать:

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

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

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

Границы ответственности нужно проектировать явно

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

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

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

Чем выше цена ошибки и чем труднее её исправить, тем заметнее должна быть точка человеческого решения. Иногда это отдельная кнопка подтверждения. Иногда — обязательный просмотр спорных полей. Иногда — запрет на автоматическое выполнение и перевод задачи в ручную очередь.

Что будет отличать зрелые интерфейсы в 2026 году

В ближайшем цикле развития ИИ-интерфейсов конкурировать будут не только сами модели. Важнее станет качество среды, в которую они встроены. Пользователь быстро привыкает к тому, что система может что-то сгенерировать или найти. Гораздо сложнее создать ощущение, что результат можно безопасно использовать в реальной работе.

Я ожидаю несколько устойчивых направлений.

Контекстные интерфейсы вместо одинаковых экранов

Информационная система будет показывать разные подсказки и действия в зависимости от роли, состояния объекта и текущего этапа процесса. Но персонализация не должна становиться загадкой. Пользователь должен понимать, почему один сотрудник видит одну рекомендацию, а другой — другую.

Меньше универсальных чатов, больше встроенных действий

Чат останется удобным способом начать исследование или сформулировать сложный запрос. Но результат всё чаще будет возвращаться в привычные компоненты: таблицы, карточки, фильтры, отчёты и панели задач. Так человек не теряет связь с архитектурой продукта.

Интерфейсы с объяснимой неопределённостью

Вместо безусловных ответов системы будут чаще показывать варианты, конфликтующие данные и необходимость уточнения. Это может казаться менее эффектным, зато снижает риск, что пользователь примет догадку за факт.

Дизайнер как автор системы решений

Роль UX/UI-дизайнера смещается от создания экранов к проектированию поведения. Нужно продумывать не только визуальный стиль, но и порядок передачи инициативы между человеком и алгоритмом, способы отката, правила подтверждения и язык ошибок.

Тестирование доверия как отдельная дисциплина

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

Проектирование интерфейса информационной системы в эпоху ИИ не означает отказ от привычных основ UX. Наоборот, исследование, архитектура, прототипирование, тестирование и последовательная дизайн-система становятся ещё важнее. Просто теперь к ним добавляется вопрос, которого раньше могло не быть: как пользователь будет взаимодействовать с системой, если она не всегда даёт один и тот же ответ?

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

Именно поэтому разработка интерфейса ИС в 2026 году начинается не с выбора модели и не с красивого промпта. Она начинается с вопроса о сценарии: что должен сделать человек, что можно поручить алгоритму, где проходит граница ответственности и как вернуть пользователю опору, если система ошиблась.