AI-генерированный интерфейс vs человеческий: где пользователь чувствует разницу

Возьмите два экрана checkout: один сгенерирован LLM по короткому промпту, другой собран продуктовым дизайнером за два спринта. На скриншоте — разница на уровне «ну, оба ок». На реальном устройстве, с реальной задачей, с реальным пользователем — пропасть.

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

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

---

## Почему вообще стоит про это говорить сейчас

Генераторы интерфейсов перестали быть игрушкой. v0, Lovable, Figma Make, плагины с MCP к компонентным библиотекам — всё это уже в проде у небольших команд. Стартап без дизайнера запускает лендинг и онбординг за выходные. Внутри корпораций джуны и продакты собирают черновики экранов без участия дизайн-отдела.

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

• Визуально всё чисто, но микровзаимодействия отсутствуют или ломаются.
• Состояния (loading, empty, error) либо забыты, либо одинаковые «на отвали».
• Копирайт сгенерирован в духе «Welcome to your dashboard» — без понимания, кто этот пользователь и зачем он тут.
• Доступность — формально соблюдена (контраст ок), фактически — кнопки 28px на мобайле.

При этом обвинять AI бессмысленно. Он сделал ровно то, о чём его попросили: «красивый экран checkout». Не «checkout, который работает у уставшего человека в метро с одной рукой на поручне».

---

## Где именно пользователь чувствует разницу

Это полезно разложить не по «качеству дизайна», а по точкам контакта. Пользователь не оценивает интерфейс целиком — он спотыкается о конкретные места.

### Первое касание: понятно ли, куда я попал

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

AI-дизайн отвечает абстрактно. Заголовок звучит как «Streamline your workflow», hero-картинка — обобщённый дашборд, CTA — «Get started». Технически всё на месте. Но конкретики — кому, зачем, почему сейчас — нет.

Быстрый тест на сегменте AI-экрана:

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

Если все три пункта пустые — это сгенерированный экран, и пользователь это почувствует не словами, а ощущением «таких сайтов миллион».

### Ввод данных: чувствуется ли, что меня ждали

Формы — самое честное место. Здесь видно, тестировали интерфейс на живых людях или нет.

Что отличает форму, которую делал человек:

• Поля в порядке, в котором их удобно заполнять, а не в порядке схемы БД.
• Маски и форматирование совпадают с тем, как человек обычно вводит данные (телефон с пробелами, карта группами по 4).
• Ошибки появляются вовремя — после ухода из поля, а не на каждое нажатие клавиши.
• Тексты ошибок объясняют, что делать, а не констатируют факт («Invalid input»).
• Автофокус, табуляция, Enter — работают как ожидаешь.

AI почти всегда генерирует форму правильную по структуре и пустую по эмпатии. Пользователь не скажет «здесь нет эмпатии» — он скажет «бесит» и уйдёт.

### Состояния и переходы: что происходит между кликами

Это самый недооценённый слой и самый явный маркер AI-сборки.

Анти-паттерны, которые встречаются почти в каждом сгенерированном интерфейсе:

• Кнопка не меняет состояние при нажатии — непонятно, сработало или нет.
• Loading — это просто спиннер по центру, без скелетона и без объяснения, чего ждём.
• Empty state — это «No data» вместо подсказки, что сделать, чтобы данные появились.
• Error state — модалка с «Something went wrong» и кнопкой «OK», которая ничего не чинит.
• Переходы между экранами либо отсутствуют, либо все одинаковые fade 200ms.

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

Вопросы для ревью любого экрана — неважно, AI или человек:

• Что видит пользователь в первые 300мс после клика?
• Что он видит, если данных ещё нет?
• Что он видит, если данных не будет никогда (пустой аккаунт)?
• Что он видит, если запрос упал?
• Может ли он отменить действие, если передумал?

Если на половину вопросов ответа нет — экран ещё не готов, кто бы его ни делал.

## Рабочий процесс: как встроить AI в дизайн так, чтобы пользователь не почувствовал шов

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

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

### Что отдавать AI, а что держать у себя

Слой	Кто ведёт	Почему
Понимание пользователя и сценария	Человек	AI не сидел на интервью
Структура флоу и состояния	Человек	Это решение, а не картинка
Раскладка, компоненты, визуал	AI + человек	AI быстрее в типовых паттернах
Копирайт, ошибки, edge-кейсы	Человек	Здесь живёт продуктовый смысл

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

## Диагностика: как понять, что в макете «пахнет AI»

Это не про эстетику и не про «слишком чисто». Это про конкретные следы, которые видно на ревью.

### Симптомы, которые легко поймать глазом

• Все карточки в макете одной высоты, потому что в реальных данных у них разная длина — но в макете данные модельные.
• Иконки набраны из одного набора, но смыслово они не про этот продукт (универсальный «график», «папка», «звезда»).
• Пустые состояния и состояния ошибок просто отсутствуют как фреймы.
• Тексты на кнопках одинаковой длины и одинаковой структуры: глагол + существительное, глагол + существительное.
• Мобильная версия — это десктоп, ужатый по ширине, без пересмотра иерархии.
• На экране нет ни одной цифры, имени или термина, которые нельзя было бы вставить в любой другой продукт той же категории.

Если ловишь три из шести — макет не готов к разработке, как бы красиво он ни выглядел в Figma.

### Вопросы, которые стоит задавать на ревью AI-макета

• Какой реальный пользовательский сценарий ты прогнал через этот экран от начала до конца?
• Что произойдёт, если в это поле прилетит длинная строка, ноль, null?
• Покажи мне состояние загрузки, пустое и ошибочное — не описание, а фрейм.
• Какие три варианта копирайта ты рассмотрел и почему выбрал этот?
• Где здесь решение, которое ты бы не принял, если бы не знал продукт?

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

## Типичные ошибки команд, которые только начали работать с AI

### Ошибка 1: промпт вместо брифа

«Сделай экран профиля пользователя» — это не задача. Это категория. AI заполняет пустоту средним по индустрии. Бриф для AI должен содержать сценарий, ограничения, тон и хотя бы один нетривиальный edge-кейс. По объёму это ближе к описанию задачи джуну, чем к запросу в поиск.

### Ошибка 2: принимать первую генерацию

Первая генерация — это эскиз, а не макет. Команды, которые ставят её в Figma и идут в разработку, потом удивляются, почему пользователи спотыкаются. Норма — 3–5 итераций с явной правкой иерархии, копирайта и состояний.

### Ошибка 3: чинить визуал, не трогая логику

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

### Ошибка 4: один человек на всю цепочку

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

## Как применять это в своём макете уже сегодня

Короткий рабочий протокол, который реально снижает количество «AI-следов» в продукте.

• Перед генерацией написать одно предложение: кто пользователь и в каком состоянии он сюда попал.
• Зафиксировать минимум три состояния экрана: основное, пустое, ошибка. Без этого не уходить в визуал.
• Прогнать копирайт вручную: убрать все «Welcome», «Get started», «Something went wrong».
• Проверить экран на реальных данных — длинных именах, нулевых значениях, отсутствии аватарки.
• Открыть макет на телефоне в реальной руке, а не в зеркале десктопа.
• Дать посмотреть человеку, который не участвовал в постановке задачи, и слушать молча.

## Короткий итог сегмента

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

## Продвинутые сценарии: где AI-макет ломается раньше всего

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

### Сценарий 1: многошаговый флоу с зависимостями

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

### Сценарий 2: интерфейс с состоянием во времени

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

### Сценарий 3: плотные рабочие интерфейсы

Админки, CRM, аналитические инструменты, профессиональный софт. Здесь пользователь — не «человек с улицы», а оператор, у которого 200 повторений в день. Ему нужны горячие клавиши, плотность, быстрые действия, минимум лишних кликов. AI по умолчанию рисует «дружелюбно и просторно», и опытный оператор сразу чувствует, что его держат за новичка.

### Сценарий 4: продукт с доменной логикой

Медицина, финансы, логистика, b2b с длинным циклом. Поле «сумма» — это не просто input, а валюта, точность, налог, округление, лимиты. AI поставит туда «$1,234.56» и пойдёт дальше. Доменный дизайнер потратит на это поле день и переспросит у аналитика три вещи.

## Как встраивать AI в командный процесс, чтобы не сломать качество

### Где AI помогает, не вредя

• Расхождение по вариантам компоновки на ранней стадии, когда ещё непонятно, куда идти.
• Черновая верстка экранов, чьи паттерны действительно стандартные (настройки, формы, политики).
• Генерация состояний, которые лень рисовать вручную: десятки пустых, ошибочных, загрузочных.
• Альтернативы копирайта, чтобы было из чего выбирать, а не «первое, что пришло в голову».

### Где AI почти всегда вредит

• Финальные экраны ключевых флоу, по которым считается выручка или активация.
• Любая работа с числами, единицами, валютами, юридическими формулировками.
• Решения об иерархии в сложных интерфейсах.
• Onboarding — потому что именно там живёт голос продукта.

## Как проверять качество AI-макета на ревью

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

### Протокол ревью в три прохода

Проход 1: без макета, по описанию. Дизайнер рассказывает голосом, что происходит на экране, какой сценарий, какие состояния. Если рассказ короче минуты — экран ещё не продуман.

Проход 2: данные вместо картинки. Смотрим только на тексты, числа и подписи. Подменяем «John Doe» на реальное имя из базы, «$1,234» — на реальную сумму с реальной валютой. Если что-то ломается по длине или смыслу — фиксируем.

Проход 3: флоу, а не экран. Кликаем от входа до результата. На каждом шаге задаём один вопрос: «что здесь может пойти не так?». Если ответа нет — состояние не нарисовано.

### Чеклист готовности AI-макета к разработке

• Есть письменный сценарий пользователя на один абзац, не на одну строку.
• Нарисованы как минимум: основное, пустое, ошибка, загрузка, успех.
• Копирайт прошёл ручную правку, а не остался дефолтным.
• Длинные строки и нулевые значения протестированы прямо в макете.
• Мобильная версия пересобрана по иерархии, а не сжата по ширине.
• Минимум один человек, не участвовавший в постановке, прошёл флоу молча.
• Названы 2–3 решения, которые дизайнер принял вопреки первой генерации.

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

## Как объяснить решение команде, когда вокруг любят AI

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

### Три фразы, которые работают на синке

• «Эту генерацию можно отдать в разработку, но мы заранее знаем, какие тикеты прилетят из поддержки на второй неделе. Давайте решим их сейчас, а не потом».
• «AI не видел наших данных. Я хочу полчаса, чтобы прогнать экран на реальной выгрузке, прежде чем фиксировать».
• «Скорость генерации — это скорость черновика, не скорость релиза. Сэкономили на рисовании, потратим на переделке».

### Чего не стоит делать в этом разговоре

• Защищать «ручной труд» как ценность саму по себе. Никого это не убеждает.
• Спорить про «вкус» и «эстетику». Это уводит в субъективное, где у всех своё мнение.
• Демонизировать AI. Команда видит, что он работает, и перестанет слушать.

Работает только одно: показать на конкретном экране, где AI принял решение, которое противоречит знанию о пользователе. Один такой пример стоит часа абстрактной дискуссии.

## Итог сегмента

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

## Финальный сегмент: что забрать в работу с понедельника

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

## Чеклист: внедрение AI в дизайн-процесс без потери качества

### До старта проекта

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

### Во время работы

• Каждый AI-экран прошёл правку текста вручную.
• Состояния (пустое, ошибка, загрузка, успех) нарисованы, а не предполагаются.
• Мобильная версия пересобрана, а не сжата.
• Сохранены 1–2 отвергнутых варианта генерации — чтобы на ревью показать, почему выбрали этот.

### Перед передачей в разработку

• Флоу пройден молча человеком со стороны.
• Тексты прогнаны на реальной выгрузке, а не на «Lorem» и «John Doe».
• Дизайнер может назвать 2–3 решения, где он спорил с генерацией.
• Понятно, какие тикеты в поддержку могут прилететь — и они либо закрыты, либо вынесены в риски.

## Анти-паттерны, которые встречаются чаще всего

### «AI сделал — мы причесали»

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

### «Покажем заказчику — там разберёмся»

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

### «У нас же есть дизайн-система, AI её подхватит»

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

### «Сэкономили день на макете»

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

### «AI не справился — значит, задача плохая»

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

## Вопросы для ревью AI-макета

Распечатать и пройти по списку, прежде чем нажать «Готово».

### Про сценарий

• Какую задачу пользователя решает этот экран — одной фразой?
• Что произойдёт, если пользователь придёт сюда не из ожидаемой точки?
• Какие состояния тут не нарисованы и почему?

### Про данные

• Что сломается, если имя — 40 символов? Если сумма — ноль? Если язык — арабский?
• Откуда взяты цифры на макете и совпадают ли они с тем, что отдаёт бэк?
• Все ли единицы, валюты и форматы дат соответствуют реальности продукта?

### Про решения

• Что в этом макете дизайнер решил вопреки первой генерации?
• Какие два альтернативных варианта рассматривались и почему отвергнуты?
• Какая часть макета не выдержит ревью через полгода — и что с ней делать сейчас?

### Про команду

• Поймёт ли разработчик, что должно произойти после клика, без дополнительного созвона?
• Знает ли поддержка, какие новые вопросы прилетят после релиза?
• Сможет ли следующий дизайнер продолжить работу, не переспрашивая автора?

## Короткий практический итог

Разница между AI-интерфейсом и человеческим ощущается пользователем не на уровне «красиво/некрасиво», а на уровне «понимает меня / не понимает». Инструмент хорошо закрывает рутину: варианты, состояния, черновики, копии без души. Плохо закрывает всё, что требует знания продукта, данных и сценария — то есть ровно то, за что дизайнеру платят.

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