Как внедрить дизайн-систему: работа с продуктовыми командами

перевод

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

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

Внедрение как пошаговый процесс

Команды внедряют систему по-разному. Новые продукты просто строятся на системе с нуля. С существующими сложнее.

«Большой взрыв» — некоторые останавливают всё, выкидывают старое, внедряют новое за несколько спринтов. Быстро, но рискованно.

Постепенное внедрение — другие встраивают систему кусочек за кусочком, параллельно с работой над фичами. Безопаснее, но дольше.

Вывод: Помогите команде выбрать подход, который снизит их риски.

Уровни прогресса

Тем, кто не идёт ва-банк, нужна дорожная карта. Покажите путь от первого коммита до полного внедрения через конкретные достижения.

Для простой библиотеки компонентов уровни могут быть буквальными:

Уровень 1: Интегрирован npm-пакет
Уровень 2: Использованы токены цветов
Уровень 3: Заменены базовые компоненты

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

Вывод: Создайте простые уровни с чёткими критериями, чтобы команды видели прогресс.

Дробите на истории

Команды живут спринтами и пользовательскими историями. Говорите на их языке:

Интегрировать npm-пакет v1.2.0 (малые усилия)
Заменить hex-цвета на токены (средние усилия)
Использовать системные чекбоксы везде (высокие усилия)

Вывод: Работайте с командой, чтобы разбить внедрение на достижимые за спринт истории.

Адаптируйтесь под процессы команды

Продукты разные. Если у вас уже есть готовые и проверенные модули — внедрить систему будет легко.

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

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

Вывод: Поймите, как команда работает, и подстройте под это интеграцию системы.

Подталкивайте к обновлениям, пока система не устарела окончательно

Подталкивайте к обновлениям, пока система не устарела окончательно

Системы стареют. Это нормально. Но нельзя допускать, чтобы продукты годами висели на древних версиях.

Вот простой критерий: "Сколько лет системе, которая от вас зависит?" Если ответ пугает — пора двигать продукт к более свежим версиям. Старая версия? Понижайте приоритет поддержки.

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

Говорите о внедрении с самого начала и постоянно

Даже когда система уже работает и вы двигаетесь дальше, будьте готовы к сопротивлению. Причём часто обоснованному. Из разговоров с продуктовыми командами (особенно с продакт-менеджерами) всплывают одни и те же темы: масштаб, приоритеты, внутренняя динамика.

Проблема № 1: "Система огромная"

Многие воспринимают систему как гигантского монстра. И это понятно — библиотека действительно большая.

Слишком большая, чтобы это вообще могло заработать. Мы не потянем массовый редизайн. Перенос продукта — это просто нереально.

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

Вывод: Система ≠ монолит. Переводите разговор из плоскости "всё или ничего" в плоскость модульного подхода.

Проблема № 2. "Система не важна… Нам и так хватает"

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

Разговор быстро скатывается в предсказуемые возражения:

— Мы уже всё сделали. Зачем переделывать?
— У нас баги горят, это важнее!
— В роадмапе три фичи. Где тут место для системы?

Говорите на их языке
Не продавайте систему. Продавайте согласованность как конкурентное преимущество их продукта.
Попробуйте так:

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

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

Проблема № 3. "Система тормозит нас"

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

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

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

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

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

Добейтесь успеха в своей рекламной кампании

Может, вы называете себя "защитником" системы или "евангелистом". Я много лет делал вид, что это не так, но признаю: я просто продаю систему.

После презентации задаю пять вопросов. Не для галочки — чтобы понять, всерьёз ли команда собирается что-то делать:

Будете внедрять?
Когда начнёте?
Когда это попадёт в дорожную карту?
Когда подключите пакет?
Когда увижу хотя бы "Hello System!"?

Звучит напористо, знаю. Но я не пытаюсь давить — просто хочу ясности. Либо есть намерение действовать, либо нет. Лучше выяснить это сразу, чем через три месяца получить "мы ещё обсуждаем".

Будете внедрять?

Команде легко сказать "да, мы должны это сделать". Но между "должны" и "будем" — пропасть.

Я формулирую так:

"Меня попросили составить список продуктов, которые точно внедряют систему, и тех, кто пока не готов. Вас записать в первую категорию?"

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

Вывод: заявление о намерениях — это только начало разговора, а не его конец.

Когда начнёте?

Когда спрашиваете "Когда?", будьте готовы к любому ответу. Кто-то назовёт конкретную дату. Кто-то начнёт мяться и уходить от ответа.

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

Но если контекст рабочий, можно уточнить рамки:

"Руководство говорит, что 24 месяца — слишком долго, поэтому..."

Тут можно предложить компромисс: "А как насчёт 12-18 месяцев?" Так вы учтёте и сроки релиза, и стратегические цели компании.

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

Когда это попадёт в дорожную карту?

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

И вот что интересно: на само планирование может уйти от 10% до половины всего времени внедрения. Половины!

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

Когда подключите пакет?

Обычно дизайн-систему подключают как npm-пакет. В репозитории продукта это выглядит как однострочное изменение в package.json:

"dependencies": {"designSystem": "1.2.0"}

Этот коммит — точка невозврата. Теперь продукт реально зависит от системы, а не просто обсуждает её на встречах. Для тимлида это первая конкретная веха, которую можно показать.

Вывод: Момент добавления зависимости (через npm или другой менеджер пакетов) — это когда система и продукт по-настоящему связываются на уровне кода. До этого всё остальное — разговоры.

Когда увижу хотя бы "Hello System!"?

Интегрировать код — одно дело. Реально повлиять на дизайн — совсем другое. Когда несколько системных улучшений выходят в продакшн, это даёт команде энергию и приносит пользу пользователям, пусть и небольшую.

Эти моменты "Привет, система!" — это маленькие победы. На обзоре спринта продуктовая команда показывает новую фичу. На roadshow системная команда рассказывает об обновлении. Обе стороны выигрывают. Начните с малого и наращивайте темп.

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

Дополнительный вопрос: "Когда это запустят?"

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

До старта работ: подключиться к подготовке, посмотреть их план, возможно, что-то подправить в системе заранее.

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

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

Главное: будьте рядом на всех этапах — так команда будет больше доверять системе.

Создайте простую систему мониторинга

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

Строки — продукты (расположите по приоритету)
Столбцы — уровень внедрения, текущий статус, заметки

Обновляйте таблицу регулярно. Прогресс можно показывать движением по столбцам слева направо, цветовой индикацией (зелёный — хорошо, красный — проблемы) или стрелками вверх/вниз.

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

Главное: Регулярно обновляйте систему мониторинга и делитесь результатами с руководством и командой.

Учитывайте реальные ограничения

Не все продукты могут полностью соответствовать системе:

Устаревший продукт не потянет крупные изменения
Жёсткая платформа не позволит реализовать современный дизайн
Технический долг блокирует нововведения

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

Вывод: Отмечайте успехи там, где они есть. Не вешайте ярлыки на продукты, которые объективно не могут пройти весь путь.

Празднуйте внедрение!

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