Как проверить дизайн-макет с ИИ: экраны, состояния и правки

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

Что будет на выходе

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

Шесть шагов от снимков до повторной проверки

1. Соберите экраны и требования. Приложите отдельные PNG/JPEG в исходном размере: desktop, mobile и доступные состояния формы. В именах укажите ширину, состояние и версию. Добавьте задачу пользователя, обязательные тексты и правила. Уберите реальные личные данные из примера.
2. Задайте границы проверки. Попросите Искру сначала перечислить доступные файлы, размеры и состояния. Если изображение не прочитано или текст неразборчив, нужен новый экспорт. Для этого сценария достаточно предоставленных снимков: ссылка на закрытый Figma-файл не заменяет их.
3. Получите наблюдения с привязкой к экрану. Для каждого замечания нужны файл, элемент, видимый факт и нарушенное требование. Отделите дефект от гипотезы: «в двух макетах разное время» проверяется по файлам, а «кнопку редко нажимают» требует данных о поведении.
4. Расставьте приоритеты. Сначала разберите то, что противоречит основному действию: неверное условие, обрезанный текст, непонятная ошибка. Затем читаемость и согласованность оформления. Просите объяснить влияние каждого пункта на задачу, а не просто проставить уровень.
5. Передайте конкретные критерии исправления. Вместо «сделать понятнее» запишите: одинаковое время 18:00, кнопка «Записаться», подпись Email видна и после ввода, ошибка объясняет нужную правку. Дизайнер вносит изменения в исходный макет и экспортирует новую версию.
6. Сравните новые снимки с прежними. Загрузите исправленные экраны в тех же размерах. Попросите пройти по ID замечаний и отметить: исправлено, осталось, не проверено. Если нужного состояния нет, пункт остаётся открытым. После визуальной приёмки отдельно проверьте собранный интерфейс.

Учебный пример: форма студии «Лист»

Студия и условия вымышлены. Мы специально подготовили макеты с несколькими ошибками и редакционный разбор. Это учебный материал, а не отчёт о запуске в Искре. Задача посетителя: оставить заявку на 25 ноября, 18:00, без оплаты на этом шаге.

Скачать весь комплект ZIP: пять PNG, требования TXT, разбор TXT, промпт TXT и учебный исходник HTML.

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

Приоритет здесь связан с задачей записи: сначала условия и главное действие, затем помощь при заполнении. Это порядок для учебного сценария, а не оценка ущерба реальному бизнесу.

Что оставить вопросом

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

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

Повторная проверка: что изменилось в v2

D01 и D02 можно закрыть для двух показанных экранов: время совпадает, кнопка соответствует заявке. D03 и D04 подтверждены снимком ошибки mobile v2: подписи видны, рядом с email есть подсказка, имя сохранено. D05 визуально улучшен; в учебном исходнике для пояснения задано 16 px. Ошибка на desktop, загрузка и успех не представлены, проверка этих состояний остаётся открытой.

Полный промпт для проверки макета

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

Проверь приложенные макеты по задаче пользователя и требованиям.

Контекст: [что за продукт и кто пользователь].
Основная задача: [например, оставить заявку на мастер-класс без оплаты].
Файлы: [desktop-default-v1.png, mobile-default-v1.png, mobile-error-v1.png].
Размеры и состояния: [1440x1000, обычное; 390x844, обычное и ошибка].
Требования: [прикреплённый brief.txt / точные тексты, условия и правила].

1. Перечисли прочитанные файлы, версии, размеры и состояния. Если снимок или текст не удаётся разобрать, скажи об этом. Не выдумывай содержимое.
2. Сопоставь экраны с задачей и требованиями. Проверь читаемость, иерархию действий, переносы, подписи полей, тексты ошибок и согласованность разных размеров.
3. Раздели результат на «Наблюдаемые дефекты», «Гипотезы и вопросы» и «Не проверяется по снимкам». У каждого наблюдения укажи файл, место, видимый факт и ссылку на конкретное требование.
4. Сделай таблицу: ID | экран/элемент | наблюдение | влияние на задачу | приоритет с причиной | конкретная правка | критерий повторной проверки. Сначала противоречия основному действию, затем читаемость, затем косметика. Не называй предпочтение дефектом без основания.
5. Не делай выводов о клавиатуре, экранном дикторе, отправке формы, сети или реальной конверсии по пикселям. Не вычисляй точные параметры шрифта и контраста по произвольному изображению. Если для измерения нужны исходные значения, попроси их.
6. Отдельно перечисли недостающие состояния. Отсутствие снимка состояния не означает, что его нет в продукте.
7. Сохрани отчёт с теми же ID в design-review.txt. Если доступно создание таблиц и PDF, дополнительно подготовь design-review.xlsx и review-notes.pdf; перечисли только действительно созданные файлы. Покажи основные выводы и в чате.
8. После загрузки мной v2 сравни одинаковые экраны v1 и v2 по каждому ID: исправлено / осталось / не проверено. Отдельно перечисли новые видимые проблемы. Не закрывай пункт без подтверждающего снимка.
Не меняй Figma, сайт и другие внешние системы. Итоговый дизайн и поведение проверяет человек.

Как принять сам разбор

• Каждое замечание проверяемо. Есть файл, элемент и видимый факт. «Сделать современнее» без требования не попадает в список дефектов.
• У правки есть точный результат. Можно сравнить старый и новый снимок и сказать, что именно изменилось.
• Границы понятны. Гипотезы не выданы за наблюдения; неприложенные экраны и поведение не помечены как проверенные.
• Повторная проверка сохраняет ID. Новые замечания добавлены отдельно. Закрытие пункта сопровождается названием файла v2.

Что сделать дальше

Зачем проверять макет по задаче, а не по вкусу

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

Список замечаний с ID помогает дизайнеру и заказчику обсуждать одни и те же проблемы. Искра помогает собрать такой список и сравнить версии; внесение правок в Figma или проверка настоящего интерфейса не происходят автоматически от загрузки снимков.

Связанные материалы

• ИИ для дизайнера
• Визуалы и баннеры по брифу
• Как составлять промпты для нейросетей