Дизайн-стройка. Как создать команду мечты за 90 дней

ЧАСТЬ I. ВВЕДЕНИЕ

Привет!

Меня зовут Андрей Богданов, я дизайн-менеджер, а эта книга о том, как построить дизайн-команду.

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

Об авторе

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

Итак, давайте знакомиться.

Я не всегда был дизайнером и тем более дизайн-лидом. В прошлой жизни (именно так я воспринимаю свои «додизайнерские» времена) я работал в банковской сфере, занимаясь выпуском и обслуживанием пластиковых карт. Я вырос до должности начальника отдела эквайринга и имел серьезную зону ответственности. Я развивал сеть банкоматов и платежных терминалов, взаимодействовал с Visa и Mastercard (в те времена мы еще дружили с международными платежными системами), сдавал отчетность в Центральный банк и писал огромные регламенты.

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

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

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

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

Я устроился в Локо-банк и, поработав там немного, перешел в Сбер. И в том, и в другом банке я был продуктовым дизайнером, поэтому подробно останавливаться на этом этапе карьеры в контексте разговора об управлении командой нет смысла. Мое становление как менеджера в тот период заключалось разве что в наблюдении за поведением коллег и анализе наблюдаемых процессов. Зато в плане продуктового дизайна менее чем за два года я получил опыт работы с самыми разными продуктами: от банковского личного кабинета до программы антифрод1[1]-мониторинга.

Но по-настоящему интересное началось, когда я перешел в ВТБ.

Я встал у истоков стрима Состоятельные клиенты, собрал с нуля дизайн-команду и выстроил все дизайн-процессы. В ВТБ я постиг тонкости дизайн-менеджмента: наем сотрудников, внедрение церемоний, выстраивание рабочего фреймворка2[1], преодоление административных препятствий и налаживание связей с руководством.

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

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

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

Параллельно с работой в ВТБ у меня было две активности: стартап Maniki и блог @na_produkte.

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

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

Следующей вехой моей дизайн-менеджерской карьеры стал переход в МТС Финтех.

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

Вместе с продуктовыми командами мы обеспечили запуск продуктов под брендом «МТС Деньги» и сервиса оплаты частями МТС Флекс, развивали линейку классических банковских услуг и увеличили присутствие финтеха в экосистеме МТС. Кроме того, я участвовал в развитии платежного модуля МТС Pay, сервисов мобильной коммерции, премиального обслуживания и инвестиционных продуктов.

На конец 2025 года, когда создавалась эта книга, я – лид команды Онлайн-каналы, которая отвечает за сайты, личные кабинеты и мобильные приложения МТС Деньги и МТС Банк. Такие команды, как наша, называют платформенными или core-командами, потому что мы определяем «правила игры», которыми должны руководствоваться все продукты, размещенные в наших каналах.

«Продуктовая карусель», о которой я писал выше, сопровождалась множеством менеджерских вызовов. Например, собрать из трех дизайн-команд одну или доказать ценность дизайн-лида тем командам, которые раньше работали без руководителя. А еще – наладить процессы взаимодействия с коллегами не только из смежных подразделений, но и из других организаций (ведь МТС – это экосистема и группа компаний).

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

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

При моей любви к написанию текстов я не мог удержаться от искушения создать книгу на эту тему, тем более что это было мне не впервой. Возможно, вы уже читали мою книгу «Как сделать дизайнеров счастливыми» или по крайней мере слышали о ней. К тому же мой опыт определенно нуждался в глубоком осмыслении, а лучший способ осмыслить что-то – рассказать об этом другим.

Так появилась «Дизайн-стройка».

О чем и для кого эта книга

Эта книга – о том, как построить дизайн-команду.

Под «строительством» я понимаю не только выделение оргструктурной единицы и наем дизайнеров, но и внедрение процессов, которые превратят этих дизайнеров в настоящую эффективную команду.

А под «командой» – дизайн-команду в самом узком смысле этого слова, то есть конкретную группу дизайнеров под руководством тимлида. Объединения более высокого уровня, вроде Департамента дизайна или всего дизайн-комьюнити компании, тоже можно назвать условными «дизайн-командами», но у них своя специфика, рассматривать которую я не буду. Например, за рамками этой книги останутся такие моменты, как выделение роли DesignOps-менеджера3[1] или подготовка карты компетенций сотрудников – подобные вопросы не решаются на уровне «атомарной» команды. При этом многие принципы, описанные в книге, универсальны и могут применяться для дизайн-подразделений любого масштаба и уровня.

Джули Чжо, бывшая вице-президент по дизайну продуктов Facebook, писала, что все задачи менеджера можно уместить в три категории: цель, люди и процессы4[1]. Это применимо и к созданию команды: дизайн-менеджеру нужно собрать вместе людей и обеспечить условия, в которых они будут успешно достигать целей команды за счет грамотно организованных процессов.

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

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

1. Создание новой команды с нуля;

2. Пересборка команды из-за реорганизации;

3. Превращение формальной команды в настоящую.

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

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

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

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

«Дизайн-стройка» – моя вторая книга.

Первая, «Как сделать дизайнеров счастливыми», отталкивается от красивой гуманистической концепции. Она заключается в том, что счастье дизайнеров – важнейшая задача их лида, которая достигается за счет алгоритмов закрытия потребностей в комфорте, интересе и прогрессе.

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

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

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

Что касается дизайн-лидов, то они – моя основная целевая аудитория, ведь именно им приходится решать задачи, которым посвящена «Дизайн-стройка». Начинающие лиды найдут для себя много новой полезной информации, а опытные получат «второе мнение», которое поможет им взглянуть на рассматриваемые проблемы с новой стороны.

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

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

Почему «стройка» и почему «90 дней»

Я долго думал над названием книги и остановился на «Дизайн-стройке», потому что «строительная» метафора при всей своей очевидности показалась мне довольно точной.

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

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

Разобравшись со «Стройкой», стоит, пожалуй, поговорить и о второй части названия – «Как создать команду мечты за 90 дней».

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

Срок 90 дней в таком качестве встречается довольно часто. Например, испытательный срок для новых сотрудников обычно длится три месяца, а многие цели и планы в компаниях формируются на квартал, то есть приблизительно на те же 90 дней. Еще один пример с сакральной цифрой – книга Майкла Уоткинса «Первые 90 дней»5[1]: именно столько времени автор дает новоиспеченному менеджеру, чтобы доказать свою состоятельность. А Патрик Ленсиони, автор книги «Пять пороков команды: практика преодоления»6[2], пишет, что новая команда за два-три месяца может добиться существенного прогресса.

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

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

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

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

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

Зачем нужны дизайн-команды

Прежде чем приступить к конкретным рекомендациям по созданию дизайн-команд, давайте попробуем ответить на основополагающий вопрос: «А зачем, собственно, вообще нужны эти команды?»

Представители других ролей – разработчики, тестировщики, аналитики, менеджеры, владельцы продукта – прекрасно уживаются в рамках единой продуктовой команды и редко стремятся создавать свои, выделенные7[1]. Так почему же дизайнеры во многих компаниях норовят обособиться и сбиваются в отдельные группы со своими лидерами?

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

Конечно, дело не в том, что продуктовый дизайн – самая сложная дисциплина. Скорее, самая противоречивая. В дизайне слишком много разных «НО», которые достойны того, чтобы рассмотреть их по отдельности.

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

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

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

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

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

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

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

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

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

Чтобы исключить такие случаи, нужно выстраивать особые процессы, которые обеспечивают высокое качество дизайна.

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

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

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

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

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

Вариант нахождения дизайн-команды внутри бизнеса не лишен плюсов, ведь он дает прочную связь дизайна с продуктом. У всех ролей – и бизнесовых, и дизайнерских – появляется общее руководство; они могут выступать «единым фронтом» и эффективно отстаивать интересы своего продукта. Впрочем, связи с продуктом можно добиться и без формального структурного объединения за счет грамотной постановки общих целей. А вот риск навязывания неоптимальных решений со стороны бизнес-лидеров – это очевидный минус схемы «дизайн внутри бизнеса».

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

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

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