Проектирование интерфейса пользователя: сдвиг в сторону ИИ

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

Мы долго строили UI как витрину: дизайнер расставил блоки, разработчик оживил, человек нажал кнопку. Теперь появляется другой контур — пользователь формулирует намерение, ИИ понимает контекст, а интерфейс буквально собирает нужную форму взаимодействия на лету. Не «новая красивая кнопка». Новый способ думать о кнопках вообще. Немного космос, немного взрыв мозга, но это уже не фантазия из питч-дека. Это Generative UI, агентные сценарии и интерфейсы, которые становятся не набором экранов, а живой системой.

От Conversational UI к Delegative UI: чат больше не главный герой

Первой стадией AI-интерфейсов стали чат-боты. У них была простая механика: человек спрашивает, модель отвечает. Иногда — предлагает ссылку, карточку товара или форму. Это Conversational UI: разговор как оболочка для действия.

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

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

До и после выглядят примерно так:

Ключевая разница — в распределении труда. В привычном интерфейсе пользователь должен знать маршрут: где меню, какой фильтр, какую форму открыть. В делегируемом интерфейсе маршрут знает система, но не превращается в чёрный ящик. Хороший UX здесь — это не «ИИ сделал всё сам», а грамотная граница между автономностью и человеческим контролем.

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

Будущее UI — не в том, чтобы заставить человека разговаривать с машиной. А в том, чтобы машина вовремя замолчала и показала правильный инструмент.

Это меняет и саму постановку UX-задачи. Мы больше не спрашиваем только «какой экран нужен пользователю?». Мы спрашиваем: какое намерение он выражает, что агент может сделать без лишних вопросов, где действие обратимо, где необходимо подтверждение, а где интерфейс обязан объяснить, почему вообще предлагает этот шаг.

Generative UI: три способа дать агенту право на экран

Термин Generative UI легко спутать с генерацией красивых мокапов по промпту. Но настоящая магия начинается не в моменте «нарисуй мне дашборд в стиле glassmorphism». Она начинается, когда интерфейс генерируется как функциональный ответ на данные, контекст и задачу.

Сейчас вырисовываются три архитектурных подхода — у каждого своя цена, свобода и зона риска.

Генерация чистого HTML: максимум пластичности, минимум страховки

Первый путь кажется самым соблазнительным: агент создаёт HTML, CSS и, возможно, JavaScript прямо под запрос. Нужен калькулятор ипотеки с необычной логикой? Вот он. Нужна интерактивная таблица для анализа? Пожалуйста. Нужен экран, которого вчера не существовало? Агент соберёт его.

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

Проблемы предсказуемы:

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

Это не аргумент «не делать». Это аргумент не путать свободу генерации с готовой UX-архитектурой.

Декларативный UI: агент говорит, что нужно, клиент решает, как показать

Второй путь намного взрослее. Агент не присылает исполняемый код, а описывает интерфейс декларативно — например, JSON-структурой: показать карточку, добавить поле ввода, вывести предупреждение, отрендерить таблицу с определёнными данными. Клиентское приложение собирает экран из разрешённых компонентов.

Именно эту логику формализует представленный Google в декабре 2025 года протокол A2UI — Agent-to-User Interface. Его идея на удивление здравая: модель не получает бесконтрольный доступ к визуальному слою, а работает через контракт. Дизайн-система остаётся хозяином пикселей, семантики и интеракций.

Для команды это означает несколько очень практичных вещей:

1. Компоненты становятся API. Не просто библиотекой в Figma или Storybook, а каталогом возможностей, доступных агенту по понятным правилам.

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

3. UX-паттерны нужно описывать формально. Что такое подтверждение опасного действия? Когда показывать ошибку? Какие поля обязательны? Агент не должен угадывать это по скриншотам.

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

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

Выбор готовых функциональных компонентов: UI как набор навыков

Третий подход — агент не строит интерфейс с нуля и не описывает каждую атомарную деталь, а выбирает готовые функциональные компоненты. Не «нарисуй список», а «используй компонент бронирования», «открой редактор документа», «покажи модуль сравнения».

Здесь важны фреймворк Tambo для React и протокол AG-UI, которые развивают двустороннюю коммуникацию агента с интерфейсом и работу с состояниями компонентов. Агенту недостаточно один раз отдать карточку: пользователь может изменить параметр, отменить действие, открыть детали, вернуться назад. Интерфейс должен сообщить это агенту, а агент — корректно пересобрать следующий шаг.

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

Дизайн-система превращается в грамматику для ИИ

В классическом проектировании UI/UX интерфейсов дизайн-система часто воспринималась как способ быстрее собирать одинаковые экраны. Кнопки, поля, иконки, документация — полезно, рационально, иногда скучновато. В эпоху AI-агентов её роль резко вырастает.

Дизайн-система становится грамматикой, на которой агент умеет говорить с пользователем.

Если в системе есть только Button / Primary / Large, она мало помогает генеративному интерфейсу. Агенту нужны смысловые сущности: «действие с необратимым последствием», «выбор из конфликтующих вариантов», «редактируемое резюме», «подтверждение с объяснением», «список результатов с уровнем уверенности». И каждому компоненту необходимы контракты:

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

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

Чем точнее дизайн-система описывает смысл компонента, тем меньше ИИ будет «творить» там, где должен работать надёжно.

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

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

Fluid AI: когда сетка приложений перестаёт быть сеткой

В июле 2026 года Samsung показала концепт Fluid AI Design System, отмеченный Red Dot Design Award 2026. Идея очень показательная: вместо привычной фиксированной сетки приложений — динамические карточки, которые ИИ может генерировать и масштабировать в зависимости от контекста пользователя.

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

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

Это фантастически сильный UX-ход, но он же поднимает пачку сложных вопросов.

Во-первых, кто контролирует приоритеты? Если система поднимает наверх один сервис и опускает другой, это уже не просто дизайн. Это распределение внимания — самой дорогой валюты интерфейса.

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

В-третьих, как не превратить контекст в слежку? Чем точнее система угадывает намерение, тем больше она знает о человеке. Этичное проектирование интерфейса пользователя здесь включает не только красивый permission-dialog, но и понятную модель данных: что анализируется, где хранится, как отключается, когда удаляется.

Наконец, есть проблема визуальной устойчивости. Мы с вами любим экспериментальные интерфейсы ровно до тех пор, пока в понедельник утром не исчезает нужная функция. Поэтому будущее UI/UX дизайна — не бесконечная жидкость. Скорее, это устойчивый каркас плюс контекстные участки, которые умеют меняться без потери ориентации.

Machine Experience: интерфейсом пользуется не только человек

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

Это называют Machine Experience Design, или MX-дизайном. И нет, это не попытка заменить UX новой модной аббревиатурой. Это расширение поля.

Человеку можно показать красивый баннер: «Ваш заказ в пути». Агенту нужен структурированный статус: номер заказа, этап доставки, дата обновления, доступные действия, ограничения на отмену, уровень доступа к персональным данным. Человек может догадаться, что серая кнопка недоступна. Агент должен получить явную причину и допустимый следующий шаг.

MX-дизайн требует навести порядок там, где команды обычно любят «разберёмся потом»:

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

В веб-дизайне это возвращает нас к старой, но внезапно ультраактуальной истине: хороший интерфейс не равен красивому скриншоту. Если продукт понятен только глазу, но не понятен браузеру, скринридеру, поисковому роботу, API и агенту, его архитектура хрупкая.

И здесь искусственный интеллект в UX/UI дизайне делает нам подарок — довольно строгий, но полезный. Он заставляет перестать маскировать хаос визуальной полировкой.

Что реально меняется в работе дизайнера уже сейчас

Нет, ИИ не «уволит всех UX/UI-дизайнеров через год». Этот лозунг эффектный, но слишком ленивый. Он путает производство пикселей с проектированием опыта.

Да, инструменты вроде Galileo AI, v0.dev от Vercel, UX Pilot и Visily уже ускоряют первый проход: помогают собрать редактируемый макет, накидать экран по текстовому описанию, экспортировать идею в Figma или код. Для раннего исследования, внутреннего прототипа, проверки информационной архитектуры это очень мощное ускорение.

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

Вот где ИИ особенно полезен:

1. Расширять вариативность до выбора направления. Не один hero-блок, а шесть композиций под разные сценарии чтения, плотность контента и уровни доверия.

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

3. Делать сценарии «до/после». Например, превратить громоздкую форму из двенадцати полей в диалог, где агент заполняет известные данные, а человеку оставляет только спорные.

4. Генерировать edge cases. Пустой список, отказ доступа, частичная ошибка, слишком длинное имя, медленная сеть, конфликтующие изменения — всё то, что обычно вспоминают за день до релиза.

5. Ускорять копирайтинг интерфейса. Варианты микро-текстов, подсказок, сообщений об ошибках и объяснений агентных решений можно получать быстро, но финальная редактура всё ещё требует человека с чувством продукта.

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

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

Готовый промпт для первого Generative UI-прототипа

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

Попробуйте отдать модели более жёсткую рамку:

Ты — UX-архитектор продукта. Спроектируй интерфейс для сценария: [вставьте задачу пользователя]. Пользователь делегирует агенту цель, но должен видеть ход критических действий и иметь возможность отмены. Используй только компоненты из списка: [перечислите компоненты]. Для каждого блока укажи: цель, входные данные, состояние загрузки, пустое состояние, ошибку, действие пользователя и событие, которое возвращается агенту. Не добавляй декоративных элементов без функции. Сначала опиши информационную архитектуру, затем предложи три варианта композиции для desktop и mobile.

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

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