Шаблон дизайн-ревью
Документ с описанием регламента проведения ревью, как описывать правки, что проверяем
Основной формат
  • 1. Разработка передает задачу на тестирование
    2. Тестировщик фиксирует основные баги, кроме дизайна
    3. Дизайнер параллельно создает документ в в FigJam:
    • Ставить тег о важности правки: критично или мини
    • Ставить тег берет разработка макет в работу сейчас или уходит в беклог
    4. Дизайнер синхронизируется с правками от тестирования на предмет повторения багов
    5. Дизайнер ставит 1:1 встречу с разработкой
Этапы проведения
  • 1. Получение доступа
    • Дизайнер получает доступ к собранной версии продукта (стенд / тестовая среда)
    • Проверяет готовность всех связанных сценариев
  • 2. Проведение ревью
    Дизайнер выполняет проверку по следующим пунктам:
    Визуальное соответствие — отступы, цвета, шрифты, иконки, состояния элементов
    Адаптивность — корректное отображение на разных разрешениях экранов
    Поведение интерфейса — анимации, hover/active состояния, ошибки и уведомления
    Контент — тексты и данные соответствуют макетам
    Доступность и читаемость — контраст, размеры шрифтов, кликабельные зоны
  • 3. Документация результатов
    • Результаты ревью фиксируются в FigJam
    • В документе указывается дата проверки, версия стенда и ФИО дизайнера.
    • Ссылка на FigJam-ревью прикладывается в задачу тестирования в Jira.
  • 4. Совместная встреча с разработчиком (1:1)
    • После загрузки ссылки на ревью дизайнер назначает 1:1 встречу с разработчиком
    • На встрече уточняются спорные моменты, обсуждаются технические ограничения и согласуется перечень правок
    Дополнительно: если объем правок большой, разделить на теги: минор или критикал
  • 5. Внесение правок разработчиком
    • Разработчик вносит правки по итогам обсуждения
    • После обновления сборки дизайнер уведомляется о готовности к повторной проверке
  • 6. Повторное ревью
    • Дизайнер повторно проверяет реализацию с учётом внесённых исправлений
    • Обновляет FigJam-документ (второй блок проверки, дата, комментарии)
    • Ссылку на итоговое ревью дизайнер прикладывает в задачу тестирования в Jira
Формулируем конкретно
❌ «маленький отступ»
✅ «Отступ между кнопкой и текстом — 16 px вместо требуемых 24 px (согласно макету)»
Привязываемся к источнику правды
Всегда указываем ссылку на макет / дизайн-систему / документацию
Добавляем визуал
  • Обязательно прикладываем скриншот
  • При возможности сравниваем «как сейчас» и «как должно быть»
Как не надо
«Кнопка кривая»
«Отступ маленький»
«Цвет не тот»
Как надо
Кнопка по высоте 40 px вместо 48 px. В дизайн-системе primary-кнопки = 48 px
Ссылка:
Скрин:
Фон блока отличается: #F8F8F8 вместо #FAFAFA
Ссылка:
Скрин:
  • Юзер-интерфейс
    • Шрифты: Проверка на соответствие бренд-гайду и читаемость
    • Цветовая палитра: Соответствие утвержденным цветам и контрастность для удобства восприятия
    • Отступы и выравнивание: Проверка гармоничности и consistency всех элементов
    • Иконки и изображения: Подходят ли иконки к контексту? Соответствуют ли изображения их назначению?
  • Юзабилити
    Уведомления и ошибки: Проверить правильность текста ошибок и уведомлений
  • Комментарии и рекомендации
    • Проблемы: Описание найденных проблем и предложений по их исправлению
    • Предложения: Рекомендации по улучшению интерфейса, если это необходимо