Дизайн-система как продукт внутри продукта

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

Она развивается параллельно с основными продуктоми, потому что увеличение функций и платформ (адаптивов) постоянно создаёт новые требования к интерфейсу и библиотеке компонентов.

Поддержка дизайн-системы — это непрерывная работа, а не разовый проект «собрали и забыли». Бэклог пополняется постоянно: появляются новые сценарии, выявляются баги, меняются требования платформ и бренда, и всё это требует обновлений.

Откуда рождаются изменения: баги / адаптив / условия

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

Компоненты — верхушка айсберга

Набор компонентов — это видимая часть дизайн-системы, но эффективность определяется иначе. Внутри дизайн-системы находятся процессы, документация, правила внесения изменений, синхронизация дизайн↔код и контроль качества.

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

При таком подходе проще формулировать «шаблон» кейса с разбором и оценивать практики.

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

Ревью фиксирует, что решение соответствует правилам, масштабируется и не ломает общую логику.

«В целом проводим ревью перед тем как передать полноценно» Никита, Додо

Роль разработки: стандарты и структура в коде

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

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

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

Взаимодействие

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

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

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

Showcase (витрина) включает в себя все ключевые компоненты и примеры, все находится в одном месте. Это облегчает и ускоряет использование дизайн-системы: дизайнер быстрее находит нужное и меньше «изобретает заново».

Мастер-файлы нужны для поддержки: в них безопаснее проводить изменения и проще контролировать качество.

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

Зачем разделять «дизайн-доку» и «dev-доку»?

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

Разделение документации снижает шум и ускоряет работу: каждый читает «своё», но опирается на единые принципы системы.

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

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

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

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

Минимальный стек

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

«.Мы используем зачастую просто Figma. То есть вот Figma, Storybook со стороны разработки и всё. Для студии этого достаточно» Сережа, Ида проджект

Откуда приходит задача в дизайн-систему

Запрос может прийти из продукта (нехватка компонента), из качества (баг), из платформ (расхождения iOS/Android) или из бренда (новые правила). Важно, чтобы запрос не «растворился»: он либо попадает в бэклог, либо закрывается быстро, если небольшой.

Как формулируется задача: топик, цели, ожидаемый результат Хорошая задача формулируется через проблему: зачем нужно изменение, какой результат ожидается и где это будет использоваться. Такой формат помогает команде принимать решения быстрее и снижает риск «сделать компонент ради компонента».

Проектирование → ревью → передача

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

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

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

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

В интервью описан подход через Figma-виджет/чек-лист, который помогает системно проверять детали и снижать ошибки на релизе.

«Можно сделать фигма виджет, в который ты можешь вставить любой файлик. И мы сделали вот этот чек-лист, если ты что-то забыл. Потому что человеческий мозг все равно может что-то забыть, что-то может выкинуть из головы недужное. Этот чек-лист как раз помогает, что компоненты тут используются правильно.» Никита, Додо

Один из важных инсайтов иследования: Дизайн-система не должна ограничивать

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

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

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

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

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

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

«Мы, например, сделали недавно автоматизацию всех токенов света из фигмы непосредственно в ассеты платформ. То есть условно ты в фигме обновил какой-то токен, либо добавил, либо изменил параметр, хекс-код тот же. Нажал синхронизировать с гитхабом, на гитхаб уходят новые токены с помощью автоматизации, которую мы сами написали, не используя никаких сторонних продуктов. Мы сами сделали, так как у нас были свои потребности. Она конвертирует все эти ассеты в ассетную платформу. То есть на iOS это x-assets, на Android это файлик xml.» Никита, Додо

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

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

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

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

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

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

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

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