ИИ в работе над макетом: ревью, состояния, доступность и handoff

От того, в каком виде модель получает экран, зависит, чему в её ответе можно верить.

• Скриншот. Самый быстрый путь. Один экран — одно изображение, целиком, в нормальном разрешении. Мелкий текст на сжатой картинке модель не читает, а додумывает. Вместе со скриншотом нужен контекст в три-четыре предложения: кто пользователь, что он здесь делает, какая платформа, что уже решено и обсуждению не подлежит. Без этого ревью получится про общие принципы хорошего дизайна, а не про твой экран.
• Несколько экранов одного сценария. Пронумеруй и подпиши каждый («1 — корзина, 2 — адрес, 3 — оплата»). Иначе модель перепутает порядок и будет критиковать переходы, которых нет.
• Прямой доступ к файлу через Figma MCP (тема «Вайбкодинг: интерфейсы»). Агент получает реальные значения вместо картинки: отступы, стили, имена слоёв и компонентов. Это единственный надёжный способ проверять то, что требует измерения: следование токенам, консистентность отступов, порядок в слоях.

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

На просьбу «оцени экран» модель отвечает вежливым набором общих мест. Рабочий способ — просить один конкретный проход за раз.

• Тест пяти секунд. Попроси модель без подсказок описать, что это за экран, для кого он и какое здесь главное действие. Модель видела миллионы интерфейсов. Если она называет главным действием не то, что задумано, с иерархией что-то не так. Это самый дешёвый тест на понятность из существующих.
• Иерархия и сканирование. Что взгляд находит первым, вторым, третьим. И совпадает ли это с тем, что важно пользователю.
• Консистентность. Одинаково ли выглядят одинаковые по смыслу элементы. Нет ли двух стилей кнопок для одного уровня действий. Единая ли логика у иконок и подписей.
• Эвристики. Проход по 10 эвристикам Нильсена с привязкой каждого замечания к конкретному элементу экрана (тема «Оценка и критика результатов ИИ»).
• Контент. Понятны ли подписи вне контекста, нет ли жаргона, хватает ли текста там, где человек принимает решение (тема «Написание контента и UX-текстов»).

Промпт для первого прохода. Давай его до того, как модель узнала хоть что-то об экране:

Посмотри на этот экран так, как будто видишь продукт впервые. Не оценивай дизайн. Ответь на три вопроса: что это за продукт и для кого; что пользователь может сделать на этом экране; какое действие здесь главное. Если в чём-то не уверен — скажи, что именно сбивает с толку.

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

Макет почти всегда нарисован для идеального случая: данных достаточно, они средней длины, интернет есть, пользователь опытный. Всё остальное всплывает на разработке в виде вопросов «а что показывать, если…». Здесь ИИ сильнее всего. Перечислять варианты он умеет лучше уставшего человека.

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

Как это выглядит на практике. Для экрана «Список заказов» в приложении доставки модель возвращает таблицу вроде такой:

Вторую строку пропускают почти все, и именно её первой находит тестировщик. Тексты для каждого состояния — следующий шаг. Он разобран в теме «Написание контента и UX-текстов», раздел «Матрица состояний».

Первый визит: объясни и дай действие

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

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

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

Результат удобно просить сразу в виде схемы на языке Mermaid. Это текстовый формат диаграмм. Claude и ChatGPT отрисуют её прямо в чате (в ChatGPT — кнопка Preview у блока кода), Gemini чаще вернёт код текстом, а в FigJam и Whimsical код достаточно вставить прямо на доску. Схему, собранную моделью, дальше можно править руками как обычную диаграмму, а не перерисовывать с нуля.

Промпт

Вот сценарий оформления заказа: корзина → адрес → способ оплаты → оплата. Найди в нём тупики: «назад» на любом шаге, отказ оплаты, возврат через день, вход по ссылке из письма в середину сценария. Верни схему на языке Mermaid (flowchart) с ветками для каждого случая.

По скриншоту модель неплохо находит то, что видно глазом и требует рассуждения. Информация, которая передаётся только цветом (красная рамка без текста ошибки). Кликабельные элементы, которые выглядят слишком мелкими для пальца. Кнопки и ссылки с непонятным вне контекста текстом. Сломанная иерархия заголовков. Плейсхолдер вместо подписи поля. Мелкий серый текст на сером фоне как кандидат на проверку.

Чего она сделать не может:

• Посчитать контраст. Она назовёт цифру, и эта цифра будет догадкой. Контраст считает плагин (Stark, Contrast и подобные) по реальным значениям цвета. Ориентир — уровень AA стандарта WCAG: 4,5:1 для обычного текста, 3:1 для крупного.
• Проверить работу со скринридером и клавиатурой. Порядок фокуса, озвучивание элементов, ловушки фокуса в модальных окнах проверяются только на живом прототипе или продукте. Руками, с включённым VoiceOver или TalkBack. Если прототип собран агентом, ему можно поручить автоматическую часть такой проверки (тема «Вайбкодинг: интерфейсы»).

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

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

Если есть Figma MCP, спецификация собирается точнее. Агент подставляет реальные токены и имена компонентов, а не описывает их словами. Это тот же мост между макетом и кодом, что и в теме «AI-first дизайн-системы», только в обратную сторону: от дизайнера к человеку-разработчику.

Обратная задача — сверка готовой реализации с макетом. Положи два скриншота рядом и попроси перечислить расхождения. Крупное (пропавший элемент, другой порядок блоков, не тот текст) модель находит надёжно. Разницу в четыре пикселя — нет.

• «Придумай дизайн экрана» вместо собственного решения. Модель выдаст самый частотный вариант, тот, что уже есть у всех (тема «Нейрослоп»). Она полезна после того, как решение принято, а не вместо него.
• Ревью как истина в последней инстанции. Замечание модели — гипотеза постороннего. Принимать его без проверки так же странно, как без обсуждения принимать каждый комментарий в Figma от человека, который не был ни на одной встрече.
• Симуляция пользователя вместо пользователя. «Пройди этот сценарий как студент, который впервые заказывает продукты онлайн» ловит очевидные проблемы и занимает пять минут. Живых людей она не заменяет. Модель не путается, не торопится, не держит телефон одной рукой в автобусе.

Промпт

Candid documentary photo of a young man in his twenties in a winter jacket and knit hat, standing in a crowded city bus in winter. He has exactly two hands and two arms, both clearly connected to his own body: his left hand, in a dark glove, grips the vertical metal pole; his right hand, bare, holds a smartphone and he types on it with the thumb of that same right hand. No other hands near him, no extra fingers, anatomically correct hands. Slight motion blur, harsh low winter sun glare through the window

Ревью одного экрана по скриншоту и аудит продукта агентом — разные задачи. Во втором агент сам проходит сценарии по ссылке или читает репозиторий, а дизайнер превращает его находки в план правок. Это разобрано в теме «UX-аудит продукта по ссылке или репозиторию».

Вот экран (приложен). Контекст: [кто пользователь, что делает, платформа]. Пройдись только по иерархии: что взгляд находит первым, вторым и третьим — и совпадает ли это с тем, что важно пользователю в этой задаче. Дизайн в целом не оценивай

Составь таблицу состояний для этого экрана: состояние, когда возникает, что видит пользователь, что нужно дорисовать. Пройди по списку: пусто, загрузка, частичные данные, ошибка пользователя, ошибка системы, нет сети, нет прав, 0 / 1 / очень много элементов, очень длинные значения. Если состояние для этого экрана невозможно — так и напиши

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

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

Вот сценарий оформления заказа по шагам: [шаги]. Найди в нём тупики и пропущенные ветки: назад с середины, отказ оплаты, возврат через день, вход по прямой ссылке на третий шаг. Верни исправленный сценарий в виде диаграммы Mermaid

Удалённый Figma MCP формально работает на любом плане, но на бесплатном Starter и на View/Collab-местах это до 20 вызовов в месяц — на проект не хватит. Для реальной работы нужно Dev- или Full-место на платном плане (200 вызовов в день, на Enterprise — 600); чтобы агент не только читал, но и менял файл, нужно Full-место.

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