Привет! Я Вика, старший продуктовый дизайнер в Cloud.ru. Моя команда разрабатывает сервисы личного кабинета облачной платформы, и сегодня я расскажу, как мы превратили фронтенд-ревью из хаотичных правок на лету в четкий и прозрачный процесс в GitLab.

Эта статья не про правила проведения ревью дизайнером, а про инструмент, который вывел код-ревью, дизайн-ревью и тестирование на абсолютно новый уровень. Инструмент, который помог нашей команде сократить количество итераций на задачу с 7 до 2—3 — расскажу, как это повторить.

Статья может быть интересна разработчикам: если вы устали от бесконечных правок в личных сообщениях и разрозненных ревью — этот гайд для вас. Дизайнерам: если хотите, чтобы правки по дизайну учитывались с первого раза, а не терялись в чатах. И продактам: если нужно ускорить выпуск фич без потери качества.

Что такое фронтенд-ревью

Это процесс проверки изменений во фронтенде, включая соответствие макетам и дизайн-системе, перед их попаданием в продакшн-среду.

Для нас, дизайнеров, фронтенд-ревью — это не просто «посмотреть, совпадает ли пиксель в пиксель». Это способ держать качество продукта под контролем и быть полноправной частью команды.

Зачем нам это нужно:

Контроль качества. Мы хотим быть уверены, что макеты реализованы точно, а не на глазок.

Экономия времени и нервов. Ошибку, найденную на этапе ревью, можно исправить за час. Пропущенную — за два дня хотфиксов в проде.

Равноправие в процессе. Мы больше не рисуем картинки, а участвуем в принятии решений наравне с разработчиками и тестировщиками.

Наш процесс и что нам в нем не нравилось

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

Несмотря на разные процессы ревью, команды сталкиваются с одними и теми же проблемами:

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

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

• Figma (у многих доступ только на просмотр, отсюда переход в другие мессенджеры) → таск-трекер → чат → потеря контекста.

• Забытые ветки в Figma → конфликты в процессе мерджа. Это огромная головная боль дизайнеров, которая провоцировала собирать макеты заново, вырезать сценарии, чтобы просто макет оказался в main-файле.

Ну и пара глобальных проблем:

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

• Дизайн → код → тесты — последовательно и долго. Это шло не в параллель, был зацикленный круг. Код → тесты → дизайн → тесты, а иногда и повторно код-ревью — куча избыточного времени на одну задачу.

Почему мы выбрали GitLab

Возможно, еще в самом начале у вас появился вопрос: зачем дизайнерам GitLab, ведь это инструмент для разработчиков? Дело в том, что как раз он помог нам собрать все в одном месте и решить несколько старых проблем — от потери контекста из-за использования разных продуктов до разбросанных правок в таск-трекере, Figma и личной переписке.

Мы почему-то сразу подумали про GitLab и вообще не ошиблись. У всех в компании есть доступ к нему, команды пользуются продуктом, и уже знают его инструментарий, он решает все наши боли одним ударом:

Все в одном месте

• Merge Requests — дизайн-ревью, код-ревью и тестирование происходят в одном интерфейсе.

• Интеграция с таск-трекером — задача, описание, ссылка на макеты — все в одном месте.

• Единая история изменений — больше не нужно искать правки в чатах или почте.

Параллельные процессы

Раньше мы работали последовательно: дизайнер проверил → разработчик исправил → тестировщик протестировал → и так по кругу.  С GitLab это движение изменилось. Теперь дизайнер проверяет верстку, разработчик сразу видит комментарии, QA начинает тестирование одновременно. Мы все находимся в одной зоне.

Никакой потери контекста

• Отбивки на почту — все получают уведомления о новых комментариях, но обсуждения остаются в Merge Request.

• Прямые ссылки — переход сразу к нужному треду одним кликом.

• Вся история на виду — можно вернуться к обсуждению через месяц и понять логику изменений. Больше никаких «Где мы это обсуждали?».

Контроль процесса

• Четкие отбивки от разработчиков — когда правки внесены, система уведомляет автоматически.

• Вся ответственность прозрачна, потому что видно, кто и когда апрувил.

• Эмодзи-реакции — быстрое согласование без лишних комментариев.

Было ли сопротивление

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

«Зачем усложнять? Чем это поможет? И так вроде нормально» → попробовали поработать по новому процессу спринт. Показали, как 3 часа поиска правок в чатах превращаются в 15 минут в GitLab. Ребята поняли, что инструмент прост и адаптирован специально для этого процесса.

��Мы так не привыкли, новый инструмент к изучению. Это же для разработчиков» → я сделала краткую инструкцию, показала на практике, чем лучше и как работает. Попросила приходить со всеми комментариями и замечаниями, чтобы отработать их в будущем.

Итоги

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

Что изменилось

Количество итераций по задаче сократилось с 7 до 3 — теперь мы двигаемся быстрее, не теряя в качестве.

Весь контекст собран в одном месте: макеты, задачи, обсуждения и результаты ревью — все прозрачно и доступно.

Дизайнеры стали полноправными участниками процесса: их фидбек учитывается наравне с код-ревью и тестированием.

Команда стала чаще обсуждать решения до релиза, а не после, и конфликтов стало заметно меньше.

Мы сократили время на релизы и повысили качество интерфейсов без дополнительной бюрократии.

Главное — фронтенд-ревью перестал быть обязательной болью. Теперь это инструмент, который помогает всей команде расти: улучшать продукт, повышать качество коммуникации и понимать друг друга без переводчиков между дизайнерским и разработческим ?

Если у вас остались вопросы или вы готовы рассказать о своем опыте внедрения дизайн-ревью, добро пожаловать в комментарии! :)