Впечатление от дизайна важно: сайт должен соответствовать характеру компании и её предложению. Но фраза «не нравится» оставляет дизайнеру слишком много вариантов трактовки. Для работы нужен контекст: что именно не подходит, кому это мешает и какой результат вы хотите получить.
Оценивайте конкретную версию по согласованным задачам. Разделите замечания о бренде, наблюдаемых барьерах, недостающем содержании и новых требованиях. Так можно сохранить выразительность дизайна и одновременно проверить, помогает ли он посетителю принять решение.
Начните с цели страницы
Опишите, что должен понять и сделать человек после просмотра. Для страницы услуги это может быть выбор подходящего формата и переход к обсуждению задачи; для кейса — понимание контекста и роли исполнителя. У разных страниц разные цели, поэтому не каждому экрану нужна одинаковая композиция или одинаковое число кнопок.
Сверьте дизайн с ранее согласованными сценариями прототипа. Если в визуальной версии исчезли условия, доказательства или способ продолжить путь, зафиксируйте изменение. Если бизнес изменил предложение уже после согласования структуры, это новое требование, которое нужно обсудить отдельно от исправления визуального расхождения.
Посмотрите на иерархию информации
Попросите человека, не знакомого с макетом, объяснить, что здесь предлагают, для кого это и куда он пошёл бы дальше. Запишите ответ и условия просмотра. Это полезная внутренняя проверка понятности, но без исследования аудитории она не доказывает поведение всех клиентов.
Сравните визуальные акценты с важностью информации. Не конкурируют ли несколько элементов за главное действие? Можно ли отличить заголовок от второстепенной подписи, ссылку от обычного текста, выбранный вариант от остальных? Вопрос не в том, чтобы сделать всё ярким: акцент должен помогать ориентироваться.
Если просите увеличить или переместить элемент, объясните причину. «Не обнаружили способ задать вопрос после чтения условий» даёт дизайнеру задачу. «Сделать кнопку вдвое больше» задаёт один вариант решения, который ещё нужно проверить в общей композиции.
Используйте реальные материалы
Проверьте длинные названия, несколько абзацев текста, разные фотографии, отсутствие изображения и дополнительные языки, если они входят в проект. Макет с короткими заглушками может скрывать неудобный перенос заголовков и потерю важных сведений на узком экране.
Сверьте содержание с планом материалов. У каждого кейса, отзыва и показателя должен быть подтверждённый источник; красивый пример в макете не становится фактом компании. Отсутствующий материал отмечают как зависимость, а не заполняют выдуманными достижениями.
Попросите показать применение повторяющихся решений на разных страницах. Согласованные кнопки, поля, карточки и состояния должны сохранять смысл. Дизайн-система помогает описать эти правила, но её масштаб должен соответствовать реальному проекту.
Проверьте доступность и состояния
В макетах можно обсудить читаемость, контраст, подписи полей и видимые состояния элементов. Попросите показать фокус, ошибку, выбранный и недоступный вариант, если они нужны в сценарии. Не ограничивайтесь красивым состоянием пустой формы.
Проверку клавиатуры, масштаба страницы и вспомогательных технологий выполняют на реализации. Изображение макета не подтверждает эти свойства. W3C включает в предварительные проверки контраст, заголовки, доступ с клавиатуры, фокус, подписи и ошибки форм, при этом подчёркивает ограниченность такого обзора. Успешная быстрая проверка не равна полной оценке доступности. Источник: W3C Easy Checks.
Запишите, что проверено сейчас и что должно перейти в критерии приёмки. Не закрывайте вопрос об удобстве ввода на телефоне только на основании мобильного изображения формы.
Пройдите путь целиком
Откройте связанную последовательность экранов: вход, изучение предложения, уточнение условий, действие и ответ интерфейса. Для мобильной версии проверьте порядок блоков, видимость навигации, длинные названия и содержание сообщений. Если переходы ещё не реализованы, перечислите недостающие состояния.
Отдельно посмотрите на возврат и исправление ошибки. Может ли человек изменить выбор, понять, что произошло, и продолжить? Дизайн подтверждения должен соответствовать реальному результату: сообщение об обработанном обращении нельзя согласовывать без понимания, что именно подтверждает система.
Используйте шаблон комментария
Один комментарий должен относиться к одному вопросу. Приложите ссылку на экран и версию, чтобы обсуждение не смешивало разные итерации.
| Часть комментария | Что указать |
|---|---|
| Место и условия | Версия, экран, язык, устройство или состояние |
| Цель | Что человек должен понять или сделать |
| Наблюдение | Что видно или произошло, без предположения о причине |
| Последствие | Как это влияет на выбор или действие |
| Основание | Требование бренда, согласованный сценарий, материал или результат проверки |
| Запрос и проверка | Какой вопрос решить и чем подтвердить следующую версию |
Учебный пример: «На мобильной странице услуги, версия D-02, после условий не видно способа обсудить проект. Цель — перейти к обращению. При внутреннем просмотре участник вернулся к верхнему меню. Просьба показать следующий шаг после условий и повторить путь на мобильном экране». Это вымышленная ситуация, а не результат исследования CoreWeb.
Если замечание связано с предпочтением, обозначьте его прямо: «Нам ближе спокойная палитра; это пожелание к образу бренда, а не измеренная проблема конверсии». Предпочтения допустимы; не нужно подкреплять их выдуманной статистикой.
Согласуйте решения и границы
Соберите комментарии в одном месте и назначьте принимающего решение со стороны заказчика. Противоречивые пожелания разных участников сначала согласуйте между собой: дизайнеру нужен выбранный приоритет или явный вопрос, а не несколько несовместимых указаний.
Для каждого пункта сохраните решение: исправить, предложить варианты, уточнить материалы, проверить в реализации или оставить без изменения с основанием. После новой версии вернитесь к исходному вопросу и запишите, что изменилось. Общая фраза «всё хорошо» не объясняет, какие вопросы закрыты.
В проекте корпоративного сайта согласование дизайна должно связывать характер компании с содержанием и сценариями посетителей. Финальный результат обсуждения — утверждённая версия и понятный список оставшихся действий, а не обещание будущей конверсии по одному макету.
Отработайте шаблон в практикуме обратной связи по дизайну: уточните три замечания и согласуйте способ проверки решений.
Отдельно проверьте комплект UI-kit: повторяемые элементы, нужные состояния и то, что передаётся в макетах и коде.
При формулировке замечаний различайте UX — опыт прохождения задачи и UI — элементы и состояния интерфейса. Это помогает выбрать подходящую проверку.