В Точка Банк нет арт-директоров или лидов, которые принимают финальные решения по дизайну. Мы верим, что сильный дизайн рождается в совместной работе, а не в «указах сверху». Чтобы сохранять консистентность и высокое качество в экосистеме продуктов, нам нужен был процесс: как переопыляться, делиться хорошими решениями и держать планку. Так появилось дизайн-ревью — одни дизайнеры отсматривают макеты других и предлагают идеи по улучшению.

На старте небольшой команде хватало нескольких ревьюеров. Но когда команда выросла до 50+ дизайнеров, процесс начал буксовать. Ревью из помощника превратилось в узкое горлышко: сроки срывались, ревьюеры выгорали, качество проседало.

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

Как всё начиналось

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

Первое время ревью вели только дизайнеры из команды дизайн-системы и процесс был очень тщательный:

• Проверяли отступы, названия слоёв, визуал, текст.

• Оценивали продуктовую логику и соответствие гайдам.

• Не пропускали кейс в разработку, пока не закроются все замечания, даже мелкие.

Такой подход работал, пока кейсов было немного. 

Первые трудности

Со временем, когда переезд набирал обороты росло и количество кейсов. И в какой-то момент ревью начало сильно тормозить процесс:

• Часто приходилось вести несколько ревью параллельно.

• Из-за скурпулёзного подхода ревью каждого кейса и очередь на ревью растягивалась на недели и даже месяцы. Рекорд — когда ревью достаточно большого сервиса длилось полгода.

• Продуктовые команды не укладывались в сроки и не могли спрогнозировать релизы.

• Ревьюеры выгорали: нужно было постоянно переключаться между чужими контекстами, спорить, объяснять, договариваться.

• Ошибки повторялись: знания концентрировались в голове у ревьюеров и не распространялись по дизайн-комьюнити.

Мы начали постепенно чинить процесс, добавляя новые роли, инструменты, подходы.

Попытки улучшить процесс

Расширили круг ревьюеров

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

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

Ввели дизайн-паттерны

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

Упростили процесс выноса компонентов в дизайн-систему

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

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

Стали делить ревью на «полное» и «упрощённое»

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

• Полное ревью — для новичков и сложных кейсов с новыми компонентами. Там смотрели на всё, от UX до пикселей.

• Упрощённое — для опытных дизайнеров, если всё собрано на паттернах. Такое ревью занимало меньше времени и не требовало доскональной проверки.

Это помогло сократить очередь и сосредоточиться на сложных задачах.

Вовлекли больше людей — через наставничество

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

Упростили инструменты

В какой-то момент мы поняли, что текущие инструменты ведения процесса добавляют трение.

Например, изначально мы оставляли комментарии к Фигме с помощью специального компонента. Но они были громоздкими и неудобными, особенно если нужно вести дискуссию. Мы отказались от них в пользу обычных встроенных комментариев — стало проще и быстрее.

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

Мы переехали в таск-трекер, автоматизировали процесс — при смене статуса бот создаёт тред в корпоративном месенджере, тэгает нужных людей. Теперь видно, где «зависла» задача и кто её ведёт. Это сделало ревью прозрачнее.

Появился бот, который оповещает, если в таск-трекере появляется новая задача на ревью. Так мы стали оперативнее их распределять и подхватывать.

Добавили градацию фидбека

Не все замечания одинаково важны. Мы ввели простую систему градации:

• Критичные — ошибки, кастомы без обоснования, нарушения UX. Без их устранения задача не проходит.

• На подумать — всё остальное. Дизайнер сам решает, что править сейчас, а что — потом.

Это помогло снять ещё один барьер. Ревью перестало быть стоп-краном из-за мелочей.

Узкое горлышко снова вернулось

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

Очередь на ревью снова начала расти. Чтобы успевать, каждому ревьюеру опять нужно было брать по 2–3 задачи в неделю. Качество заметно проседало.

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

• «Ревью сильно тормозит задачи, проще не выносить кейс вовсе».

• «Ощущение, что ищут ошибки, а не помогают улучшить».

• «Если есть кастом, обсуждение может затянуться на недели»

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

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

Новый подход

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

Лидер мог бы распределять кейсы внутри группы, а участники — становиться ревьюерами друг для друга. Так ревью стало ближе к ребятам, которые в контексте продуктов, а не «внешней проверкой».

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

• Сейчас дизайнер приносит кейс на ревью в свою мини-группу, а лидер оценивает его сложность и назначает ревьюеров из состава группы. Если в кейсе возникают вопросы к паттернам, компонентам или продуктовой логике, он подключает дизайн-систему или других экспертов.

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

• Теперь каждый дизайнер в комьюнити — потенциальный ревьюер. Это не привилегия «старших», а часть роли дизайнера.

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

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

• Описали чеклисты и памятки, чтобы сделать процесс прозрачнее:

  • как нужно подготовить кейс, чтобы быстрее пройти ревью (гигиена, паттерны и т.д.);

  • как правильно ревьюить чтобы помочь по делу, а не «душнить по мелочам»;

  • как правильно доносить фидбек;

  • что может повлиять на сроки ревью.

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

• Оценили полезность ретро и решили хотя бы раз в полгода проводить рефлексию по процессу, чтобы снова не скатиться в автоматизм и вовремя вносить улучшения.

Что это дало

Скорость
Теперь ревью в среднем занимает 2–3 дня, а не недели. 

Масштабируемость
Процесс сможет работать и на 100+ дизайнеров без выгорания и просадок в качестве.

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

Гибкость
Каждая мини-группа может адаптировать ревью под свой ритм: договориться о сроках, правилах. Процесс подстраивается под команду, а не наоборот.

Переопыление
Через ревью распространяются идеи: кто-то заметил новое решение, кто-то подсветил паттерн. Это уходит дальше по командам, а не оседает на нескольких ревьюерах.

Фокус на важном
Отделив критичное от необязательного мы перестали закапываться в микроправки и сосредоточились на действительно важных моментах.

Выводы

Не держите ревью централизованно
Делегируйте в команды — вместе с доверием и ответственностью.

Делите фидбек
Не всё должно блокировать релиз. Важно понимать, где критично, а где «на подумать».

Зафиксируйте чеклисты и памятки
Это снижает неопределённость, делает ожидания понятными и экономит время.

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

Упрощайте и автоматизируйте
Боты, нативные инструменты и снижения ручника позволяет сильно экономить время.

Не забывайте, зачем вы всё это делаете
Процессы должны помогать. Если мешают — меняйте.

Мы ещё не всё отточили, что-то до сих пор меняется. Но теперь у нас есть система, которая не ломается от роста, и комьюнити, которое умеет меняться вместе с ней.

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