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

Например, ревью: если проверять каждую задачу так же тщательно и подробно, как раньше, на него начинает уходить больше времени. При этом полностью отказываться от проверки тоже не стоит — качество по-прежнему требует внимания. Роман Горшков, AI-дизайн-директор Битрикс24, рассказывает, как перестроить правила ревью: для разных задач сделать разный уровень проверки. Это поможет команде работать быстрее и при этом сохранить качество и самостоятельность дизайнеров.

Почему прежнее ревью становится тормозом

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

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

Светофор задач: зеленые, желтые, красные

Задачи можно разделить по степени влияния на продукт по принципу светофора.

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

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

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

При этом цвет определяется не размером задачи и не количеством часов на ее выполнение, а влиянием на пользователя и продукт. Небольшое изменение может оказаться «красным», если оно затрагивает критичный сценарий, а крупная по объему задача — «зеленой», если ее влияние на продукт минимально.

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

Цвет задачи можно определять по заранее заданным критериям и подробной таблице, которую передают платформе для вайбкодинга, например, Коворк/Коду. В итоге он правильно распределяет задачи по уровням. Если случай пограничный, стоит выбирать более осторожный вариант: между зеленым и желтым ставить желтый, между желтым и красным — красный. При этом платформа обязательно объясняет в чате свой выбор: например, пишет, что сомневается между зеленым и желтым и поэтому выбирает желтый. Если позже становится понятно, что задачу можно было отнести к другому уровню, решение можно скорректировать.

Как при этом не потерять качество

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

Как при этом не потерять людей

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

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

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

Как меняется роль руководителя

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

Меняется и темп работы. Раньше ревью могло блокировать задачу: пока руководитель не посмотрел результат, работа не двигалась дальше. Зеленое ревью этого не требует — задача продолжает выполняться, а руководитель может посмотреть ее тогда, когда у него появится время между другими делами и созвонами. Это снижает нагрузку и на самого руководителя, и на команду: процесс не останавливается из-за ожидания проверки.

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

Почему переход занял полгода, а не день

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

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

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

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

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

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