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

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

Компания может попасть в ловушку, покупая всё новые ИИ, чтобы ускориться. Умственный ресурс команды начинает тратиться на освоение этих сервисов. Вместо ×2 к скорости релизов бизнес получает ощущение, что «нейросети не взлетели». О том, почему так происходит и как DesignOps помогает решить эту проблему, рассказал Роман Горшков, арт-директор Битрикс24.

Наука против многозадачности

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

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

Исследования переключения внимания (Sophie Leroy, 2009) показывают, что на возврат в контекст уходит ощутимое время, при этом растет число ошибок, а сложные решения даются тяжелее. Чем больше параллельных «контекстов» висит на человеке, тем большая доля его рабочего дня уходит не на работу, а на постоянные переключения между ней.

Схематично это выглядит так:

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

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

• Главный пожиратель этого ресурса — переключение, то есть вынужденная смена контекста.

И постоянным источником этих переключений как раз и выступает операционка: рутина, которая постоянно возвращает человека к второстепенным задачам.

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

Чтобы разорвать этот круг и наращивать объем без работы на износ, в Битрикс24 выделили отдельную роль — DesignOps.

DesignOps в эпоху нейросетей: фильтр от ИИ-шума и щит для команды

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

Покажем на примере. Допустим, вышел новый мощный ИИ-генератор или плагин для Figma, который потенциально может ускорить отдел.

Как это происходит без DesignOps. Инициативный дизайнер бросает текущие задачи, идет оформлять подписку, разбирается в интерфейсе, упирается в ограничения, разочаровывается и возвращается к старым проверенным инструментам. Время упущено, продукт не продвинулся, а у соседних задач «отъели» внимание. Либо дизайнер сделал «быструю разведку», не углубился в сервис и не смог разглядеть реальной пользы.

Как это происходит с DesignOps. Отслеживание новинок — одна из прямых обязанностей специалиста, поэтому он реагирует на новый инструмент за 1–2 дня, до пяти рабочих дней тестирует его на реальных кейсах компании, собирает библиотеку промптов и упаковывает все в понятный пошаговый гайд. И только потом инструмент попадает к продуктовому дизайнеру — уже как готовая, обкатанная «волшебная кнопка», которая сразу приносит пользу.

Разница в цифрах за первый год работы в таком формате:

Опыт внедрения: инструментарий

Citizen Development: почему наши дизайнеры начали писать код

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

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

С появлением мощных LLM ситуация изменилась. DesignOps открыл для команды направление Citizen Development, то есть «гражданская разработка» — когда рабочие IT-решения создают люди без профильного инженерного образования. Современные модели позволяют делать это на естественном языке: специалист описывает нужную логику словами, а модель превращает ее в работающий код.

В Битрикс24 специалисты DesignOps взяли на себя роль таких «гражданских разработчиков» и с помощью ИИ начали самостоятельно собирать внутренние инструменты. За год их получилось три:

• плагины для Figma, которые автоматически проверяют макеты и меняют атрибуты в проектах;

• a11y-помощник — инструмент, который проверяет интерфейсы на соответствие стандартам доступности;

• ИИ-бот для базы знаний, помогающий команде быстро находить нужную информацию (заодно сюда же легли проверки локализаций и токенов).

Опыт внедрения: AI-driven Design и Citizen Development

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

Выгода здесь ощутимая:

1. Экономия ресурса разработки: мы не отвлекаем дорогих фронтенд-инженеров от развития основного продукта. Дизайн-команда стала автономной в плане базовой автоматизации.

2. Скорость внедрения: путь от идеи «нам нужен инструмент» до работающего плагина сократился до нескольких дней.

3. Рост эффективности: доля использования ИИ в реальных дизайн-процессах выросла с <5% до 20%, и это не игрушки с генерацией картинок, а функциональные скрипты, которые экономят часы ручного труда.

Результат: +40% к объему без выгорания

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

За год активной интеграции DesignOps в Битрикс24 мы замерили результаты. Главный инсайт — пропускная способность отдела кардинально выросла. При том же составе команды без найма новых продуктовых дизайнеров объем выполненного релиза увеличился примерно на 40% (в закрытых тасках и сторипоинтах), но по нашим расчетам, может вырасти еще вдвое.

Но для бизнеса важнее даже не сама цифра, а то, какой ценой она достигнута.

Обычно резкий скачок производительности означает переработки, выгорание и работу на износ. В нашем случае, благодаря тому, что DesignOps забрал всю рутину, субъективное ощущение нагрузки у дизайнеров спустилось из красной зоны («не комфортно») в зелено-желтую («объем комфортный, готов брать еще»). По нашим внутренним замерам, людям стало примерно вдвое легче. Это и есть ответ на вопрос, можно ли масштабировать производство без насилия над командой.

Попутно решилась вечная проблема трения между дизайном и разработкой. DesignOps стандартизировал работу с токенами и проактивно занялся межкомандными процессами — в результате число эскалаций проблем со стороны разработчиков сократилось (с 6 до 2 за релиз), а на разработку фронтенд-части стало уходить на 1–1,5 часа меньше.

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

Изменилось и качество «бытовых» процессов, которые обычно никто не считает, но которые ежедневно съедают время:

В сухом остатке: масштабировать команду через DesignOps банально выгоднее. Нанять еще одного обычного дизайнера, значит получить разовый линейный прирост. Нанять специалиста DesignOps — это получить системный буст всего отдела, который окупается в первые же месяцы за счет сокращения времени на онбординг (с 10 до 3 дней) и сведения простоев к нулю.

Чек-лист для бизнеса: когда пора нанимать DesignOps

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

Как понять, что вам уже пора? Проверьте себя по трем симптомам:

1. Команда выросла до 5+ человек. По нашему опыту, именно в такой команде набирается нужный объем операционки, чтобы делегировать ее отдельному DesignOps.

2. Лиды и сеньоры тонут в рутине. Вы платите им за продуктовую стратегию, а по факту они обновляют UI-киты, пишут регламенты и ищут потерянные макеты, потому что дизайнеры не могут продолжить работать.

3. Инновации запутывают процессы. Попытки внедрить тот же ИИ или новый софт приводят к остановке работы и стрессу, а не к ускорению.

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

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

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