Юра Ветров: 32 паттерна дизайн-менеджмента

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

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

Эта логика объясняет и устройство материала. В нём нет обещания, что компания должна пройти единственный правильный маршрут от точки, А к точке Б. У разных бизнесов разная стадия развития, разный запас ресурсов, разная срочность проблем и разные ограничения. Паттерны нужны, чтобы сначала понять текущее состояние, а затем собрать собственный маршрут изменений.

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн-система для Ветрова — не библиотека компонентов в Figma и не способ навести визуальный порядок. Она начинает работать только тогда, когда живёт в коде и используется продуктовой командой при поставке изменений. Если система существует только в дизайнерском файле, она улучшает работу дизайнеров, но не гарантирует единообразия, скорости и качества на стороне реального продукта.

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

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

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

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

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

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

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

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

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