DesignOps: освобождение от рутины и рост продуктивности дизайн‑команды. Опыт Битрикс24
Большинство дизайнерских команд сталкиваются с идентичными сложностями: разрозненностью коммуникаций, дублированием задач и потерей единообразия в процессах и инструментах. DesignOps — современный ответ на эти вызовы. Art‑директор Битрикс24, рассказал почему за DesignOps — будущее и поделился личным опытом перехода на эту методологию в своей команде.
Что такое DesignOps
DesignOps — это «операционная система» дизайн‑команды: это понятие включает в себя процессы, инструменты, коммуникации и метрики. Простыми словами, DesignOps — это люди (и AI‑агенты), которые создают среду для работы дизайнеров. Цель DesignOps — повышение эффективности работы команды через системный подход.
Чем больше команда, тем острее становится потребность в отдельном департаменте DesignOps. По опыту Битрикс24, отдельного специалиста DesignOps имеет смысл выделять в команде от 5‑ти человек.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Как понять, что вам нужны DesignOps‑специалисты
Стоит сказать, что функции, которые выполняет DesignOps, в команде дизайнеров существуют всегда — их обычно забирают на себя арт‑директора, тимлиды, продукт- и проджект‑менеджеры, дизайнеры дизайн‑систем, рядовые дизайнеры и т.д. Вопрос лишь в том, стоит ли передавать эти функции отдельному департаменту DesignOps.
На этот вопрос можно ответить эвристикой: если вы живёте в 2026 году и работаете в команде от 5‑ти человек, то стоит. Сегодня — по умолчанию стоит. В команде до 5‑ти человек, функции DesignOps могут быть осознаны на уровне лидера команды. Дальнейшее движение выглядит разумным из соотношения 1 DesignOps на 5 продуктовых дизайнеров, без учёта руководителя или лида. Это связано с тем, что темп выпуска нового инструментария и новых методологий заметно вырос за последние пять лет.
Какие функции выполняет DesignOps в команде
В основе DesignOps лежит фреймворк системного мышления в направлении организации процессов дизайн‑команды и модернизации её инструментария.
Дизайн‑система как драйвер консистентности и эффективности. DesignOps может вырасти из направления дизайн‑системы (как это было в команде дизайнеров Битрикс24) — но это не строгое правило. DesignOps‑специалисты могут быть также приглашены извне. При этом дизайн‑система остается одной из самых больших функций DesignOps.
Одна из задач DesignOps — поддерживать популярность языка дизайн‑системы в компании, развивать его и трансформировать. Иначе — теряется контроль над качеством UI. В Битрикс24, например, каждая задача на UI проходит ревью DesignOps, в ходе которого мы меняем компоненты на более удобные, убираем ненужный кастом и так далее.
В свете широкого распространения AI‑инструментария на DesignOps также ложится задача постоянного мониторинга новинок: специалисты должны фоново изучать новинки, тестировать, быть готовыми оперативно сделать нужные допилки и интегрировать новый инструмент в работу команды. Но об этом стоит поговорить отдельно.
Управление инструментарием. Мы разделим инструментарий дизайнера условно на AI‑решения и НеAI‑решения (Figma, Blender, гайды для команды).
Отслеживать AI‑инструментарий нужно постоянно. Если переложить эту заботу на продуктовых дизайнеров, то их работа будет постоянно блокироваться, так как количество тестов, которые нужно выполнять, огромно. Для DesignOps тестирование нового инструментария — часть их основной работы. Они готовят выборку, делают множество тестов, отрабатывают маршрут и упаковывают его в краткие обучающие материалы и памятки для дизайнеров.
Объем НеAI‑решений также остается внушительным: дизайнеру нужно быть оркестратором разных инструментов. Например, в Битрикс24 мы считаем, что простая продуктовая 3D‑графика должна выполняться обычным продуктовым дизайнером. Здесь выходят DesignOps: они разбираются в вопросе, выбирают инструмент, создают пошаговый гайд, собирают набор сцен с компетентными специалистами и подготавливают библиотеку материалов. Это снимает нагрузку с продуктового дизайнера: ему не нужно изучать софт или что‑то кастомизировать — всю работу уже сделал за него DesignOps.
При этом DesignOps не только заботится о графических пакетах или графических AI‑решениях. Они также ответственны за то, как можно применить LLM‑модели или другие инструменты в рабочем процессе дизайн команды — и тем самым его упростить. Например, в Битрикс24 мы имеем специализированных ботов и плагины Figma, которые проверяют локализации и токены, а также проверяют интерфейсы на соответствие стандартам доступности и так далее.
Работа с людьми и процессами. На DesignOps ложится важная обязанность по онбордингу новых членов команды, управлению базой знаний и обучению действующих сотрудников новым процессам, а также формированию культуры обратной связи для поиска узких мест в процессах.
Пример из жизни: когда мы стали внедрять в Битрикс24 доступность интерфейса, потребовалось несколько разных обучений для разных департаментов: разработка, писатели, дизайнеры, продукты. Потому что всем нужно было отслеживать требования доступности в своей зоне ответственности.
Подготовкой документации занимались DesignOps. Это хороший пример сложного проекта. Любой новый процесс, KPI, слой в продукте требует грамотного описания. DesignOps также занимаются расписанием обучающих встреч и семинаров для команды.
В самом зрелом состоянии DesignOps также участвует в рассмотрении новых кандидатов на вход в команду, в создании и корректировке KPI для команды и в итоговом перформанс‑ревью как самостоятельные агенты.
Внутренняя PR- и полит‑функция. Помимо внедрения инструментария и поддержки процессов, для любых компаний важно следить за пользой, которую приносит дизайн‑направление.
DesignOps подготавливают внутренние презентации, ведут внутренние медиа, обеспечивают платформу для общения департаментов с другими командами. Это дает возможность показать значимость работы дизайн‑команды в масштабах всей компании.
В зрелом состоянии DesignOps также участвуют как медиаторы в обсуждении крупных изменений и проектах, где задействованы разные департаменты.
Автоматизация и AI‑агенты. Автоматизация и AI — это отдельный слой DesignOps. Если какая‑либо функция может быть качественно заменена или частично заменена AI‑агентом, DesignOps рассмотрят такую возможность. Например, в Битрикс24 популярны AI‑агенты, которые помогают работать с базой знаний в различных сценариях.
В этом отношении DesignOps держит руку на пульсе и как только можно сделать какую‑то автоматизацию — делает её. Мы используем автоматизацию в Битрикс24 для статусов задач, ревью и прочего — всё автоматизировано для дизайн‑команды.
Сегодня в условиях, когда AI на слуху и повсеместно проводятся автоматизации, одна из важнейших ролей DesignOps — это донести до людей, для чего делаются эти процессы и к какой картине работы они приведут в будущем.
DesignOps в Битрикс24: личный опыт в цифрах и фактах
Мы начали внедрять DesignOps для дизайн‑команды Битрикс24 полтора года назад. Первые шесть месяцев ушли на эксперименты и тестирования, затем мы перешли в активную фазу. Спустя год жизни с DesignOps‑департаментом мы готовы подвести первые итоги:
- Соотношение дизайнеров и DesignOps: 12/3. Сейчас в планах компании рост до 15/3.
- AI инструменты и скорость вывода фич: В год, когда появился DesignOps, мы внедрили в работу 5 новых инструментов (4 из них на базе AI: Kling AI, HeyGen, Genspark, Cursor).
- Психологический климат: ранее в команде часто возникали вопросы, обсудить которые в течение рабочего дня не было возможности. Это влияло не только на эффективность, но и на эмоциональное состояние команды. DesignOps cделал процессы прозрачными: должностные инструкции, KPI и систему оценки. Понимание, по каким критериям оценивается работа и чего ждать от процесса — и снятие беспокойства сотрудников для нас одно из главных достижений DesignOps.
- Поиск актуальной версии компонента: сокращён с 10–120 минут до менее чем 5 минут благодаря единой библиотеке и поддержке DesignOps.
- Качество макетов: дизайн макеты превратились в официальные документы (которые передаются в разработку), где фиксируются все нюансы решений. До появления DesignOps часто возникали моменты, когда новые маленькие изменения или корнер‑кейсы не фиксировались в макетах.
- Взаимодействие с разработкой: в среднем мы получали 5 обращений по процессу за релиз (6 месяцев) от разработки. За последние полгода у нас не было ни одного обращения благодаря тому, что DesignOps оперативно реагировали на узкие моменты в процессе и принимали меры по их устранению.
- Консистентность дизайна: от 3‑5 вариантов одного сценария к единому стандарту. DesignOps не только приводит отдельные примитивы к одному состоянию, но и целые флоу.
- Онбординг новичков: 7 дней без системы против 3 дней по структурированному плану. Раньше новый человек адаптировался гораздо дольше — до нескольких недель — пока изучал большую дизайн‑систему и внутренние процессы. Сейчас, поскольку база хорошо структурирована, уже после 3‑х дней планового онбординга сотрудник готов переходить к задачам.
DesignOps принес в команду упорядоченность, четкие данные и стабильные процессы.
Как создать функцию DesignOps в команде
Осознание функций DesignOps. Нужно составить список функций, которые выполняет DesignOps и понять, как они распределены сейчас. Часто бывает так, что часть из них лежит на руководителе, часть — на одном из лидов, еще часть — на аналитике или менеджере продукта.
Сформировать профиль должности DesignOps. На основании тех функций, которые будут сформулированы, нужно фактически сформировать что‑то вроде вакансии: список всех обязанностей, которые будут в зоне ответственности DesignOps‑специалиста. Позже этот список можно трансформировать в полноценное описание вакансии с некоторыми допилками.
Оценка DesignOps. На следующем этапе важно понять, какие показатели работы DesignOps будут служить критериями оценки и какие KPI будут их обязанностям соответствовать. Сразу все KPI предусмотреть не получится, но важно первоначально наметить, какие показатели в целом можно для этого использовать.
Например, если обязанностью DesignOps является налаживание и поддержка процесса в дизайн‑команде, то KPI может быть «количество обращений с вопросами о процессах команды», или «время онбординга нового сотрудника».
Не все критерии будут количественными, часть из них обязательно будет качественными, чтобы на уровне руководителя снимать общий климат и дух команды. Важно понимать, усиливает ли DesignOps команду или, напротив, создает лишнее напряжение. Именно для этого необходимы качественные критерии оценки.
Поиск DesignOps‑специалиста. Это самый сложный этап. После формирования всех материалов и принципов нужно начать искать людей, которые подойдут под это описание. Критерии, по которым искать людей — это базовые фундаментальные вещи: структурность, soft‑skills и так далее. Плюс человек должен иметь компетенцию и опыт хотя бы в некоторых из указанных областей.
DesignOps как функция появилась три года назад, но все еще является достаточно «молодой» для рынка: поэтому у многих довольно нечеткое понимание, что из себя представляет DesignOps. Найти на рынке специалиста, который будет закрывать все обязанности, будет непросто. Лучше ориентироваться на наличие если не прямого, то смежного опыта.
Без чего действительно будет трудно сейчас DesignOps — это без опыта дизайн‑системы. DesignOps должен быть изначально дизайнером, а скорее дизайнером‑организатором. Такие дизайнеры есть в B2B‑продуктах. Это люди, которые работали со сложными сценариями и логическими структурами. У них не обязательно должны быть большие амбиции именно в креативной области, то есть в поиске «вкусных» визуалов.
Самый главный критерий — это то, чтобы человек комфортно себя чувствовал в этой роли. DesignOps больше про системность, чем про креативную составляющую. Поэтому обычный дизайнер, заточенный на создание креатива, получив обязанности DesignOps, может быстро потерять мотивацию.
Поддержка процессов. Не стоит питать иллюзий, что наняв DesignOps, процессы пойдут своим чередом. Новый специалист не будет знать продукта и специфики работы в компании. Поэтому на первых порах руководить оркестром DesignOps придется более опытному специалисту: их нужно обучить подходам, которые приняты в компании, и работе с текущей командой.
В противном случае DesignOps либо потратить очень много времени на то, чтобы разобраться в процессах, либо вообще не справятся с этой задачей — такой риск тоже есть. Поэтому онбордингом DesignOps ни в коем случае нельзя пренебрегать.
То есть DesignOps совместно с лидом нужно провести через все важные вехи, обучить работе с людьми, процессам, ревью и так далее. Погружение должно быть постепенным: резго сгрузить всю ответственность и обяанности на нового специалиста будет большой ошибкой.
Обязанности DesignOps в каждой компании будут разными, хотя будет оставаться определенный общий знаменатель. Поиск специалистов — это вопрос как чутья руководителя, так и опыта в подборе персонала. Маршрут поиска и онбординга DesignOps будет схож, но качество и плавность его прохождения — это уже дело искусства.
