<aside> ℹ️ Примерное время на прочтение: 10 минут. Обязательный к использованию плагин PixelPerfect для Google Chrome.

</aside>

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

Качественно проведённый авторский надзор повышает качество продукта.

Схема работы над задачей от дизайна до релиза

надзор.png

  1. Дизайн. Макеты подготавливаются для вёрстки, ссылка на них передаётся разработчику.
  2. Разработка. Производится разработка (вёрстка). После окончания разработки — результат работы передаётся дизайнеру любым из доступных способов: ссылка, архив или локальное разворачивание проекта. Если разработчику чего-то не хватает в дизайне для реализации, то ему следует обратиться к дизайнеру для решения вопросов.
  3. Надзор. Дизайнер проводит ревью разработки. Если он не находит проблем, несоответствий, багов, следующим этапом становится реализация.
  4. Релиз. Также полезным будет, если дизайнер проверит качество разработки (вёрстки) после релиза «на бою». Бывает, что при авторском надзоре до релиза всё хорошо, а после — появляются баги по различным причинам.

Для чего нужен авторский надзор

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

Процесс авторского надзора

  1. Запросить сборку (или ссылку на неё) и доступ к ней у разработчиков, установить её.
  2. Внимательно протестировать функционал, обращая внимания на все детали. Необходимо проверить не только корректную работу клиентских сценариев, но и соответствие UI макетам (отступы, стили текста, корректные экраны ошибок и тд.)
  3. Найденные недочёты необходимо оформить в удобном для дизайнера и разработчика виде: в Figma, в Jira или иначе. Самое главное, чтобы выбранный способ передачи и фиксации правок был понятным.
  4. Передать баг-репорты разработчикам.
  5. Провести авторский надзор повторно для проверки исправления багов.