Повышаем качество продукта и уменьшаем количество багов за счет частых маленьких ревью

Anna Belenko
3 min readSep 29, 2021

При создании продукта дизайнер и команда разработчиков плотно работают вместе. От их взаимодействия зависит скорость выполнения задач и качество продукта. Чем плотнее взаимодействие, тем лучше на выходе будет продукт. Практика, которая улучшает продукт — это дизайн ревью верстки. Я расскажу о подходе к процессу ревью, который сократил время, но при этом сильно повысил качество наших продуктов.

Цель

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

История

Каждый продукт регулярно выпускает обновления — релизы. Релиз включает в себя исправление багов или добавление нового куска интерфейса. В год релизов может быть несколько штук, а может быть и несколько десятков.

Проверка верстки интерфейсов проводилась один раз перед релизом.

Как результат, перед дедлайном дизайнеру нужно проверить большой объем работы, отправить правки команде разработчиков, а им — внести корректировки. Изменения, в свою очередь опять должен был проверить дизайнер. И так пока интерфейс не будет доведен до идеала. Чем длиннее итерация, тем больший объем работ нужно проверить всем участникам процесса.

Проведение ревью усложняется особенностями B2B-продуктов. Как правило, они представляют собой большие системы с множеством специфических состояний и сложных сценариев использования.

Проблемы, с которыми мы столкнулись

  1. Разработчики не успевали исправлять все баги, и эти баги приходилось переносить на следующий релиз. И так по кругу: мы никогда не получали вид продукта, каким его задумывал дизайнер и продакт-менеджер.
  2. Некоторые состояния интерфейса невозможно было сгенерировать, чтобы проверить ошибки.
  3. При ежемесячных релизах дизайн-ревью становится трудозатратным.

Решение

Мы нашли следующее решение этих проблем:

  • разработчик добавляет дизайнера в ревьюеры задачи в приложении для отслеживания или в таск-менеджер.
  • По ходу работы разработчик прикрепляет скриншоты всех состояний и не может закрыть задачу без подтверждения дизайнера. То есть пока дизайнер не подтвердил, что все верно сверстано, задача не закрывается. Разработчик исправляет баги сразу “не отходя от кассы”. Для ревью верстки мы используем Team Foundation Server или Collaborator. Второй уже устарел, но в этом приложении есть возможность прикрепить метку на проблемное место сразу на скриншот. Таким образом не надо открывать графический редактор, чтобы указать проблемное место на скриншоте. Это сильно убыстряет работу. Также, в Collaborator можно добавить видео или гифку.
  • В Team Foundation Server возможности ставить метки нет, поэтому разработчики прикрепляются скриншот верстки с наложенным поверх прозрачным макетом Figma. Для этого используется плагин PerfectPixel. С помощью этого плагина разработчики накладывают полупрозрачное изображение поверх сверстанного интерфейса.
Интерфейс плагина PerfectPixel

Чего мы добились

  • Дизайнеру нужно проверять небольшие куски интерфейса, а разные его состояния можно отследить. Это делается на протяжении всего релиза. Благодаря вовлечению самих разработчиков, погружение в продукт получается более полным.
  • Исправление багов равномерно распределяется на все время до релиза, соразмерно заведенным задачам, что не вызывает перегрузки и дизайнеров, и разработчиков перед релизом, тем самым снимая многие боли.
  • Разработчику не приходится вспоминать, что он верстал, он быстро получает фидбек дизайнера и исправляет”по горячим следам” еще помня код, который писал.
  • Разработчики учатся, и со временем количество заводимых багов на UI уменьшается.
  • Раньше мы проходились по всему продукту перед каждым релизом, что занимало очень много времени и местами было не очень эффективно. При новом подходе глобальное ревью дизайнер проводит только 2 раза в год. Ранее у каждой команды разработчиков проводилось по несколько ревью за полгода, причём в разное время.
  • Качество продукта становится выше, так как все баги успевают исправить.

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

--

--