Предложить кейс

Никита — «Свобода в ДС: почему детач — это не нарушение, а инструмент»

Главное

Ключевые тезисы:

  1. DS в Dodo строится на принципе свободы: детач компонента — не нарушение, а инструмент тестирования гипотез. Дизайн-система не должна быть ограничителем.
  2. Переключение платформы iOS → Android — через мод токенов, автоматически: шрифты, цвета, компоненты меняются без ручной работы.
  3. Полная автоматизация пайплайна: токены, иконки и (в планах) иллюстрации уходят из Figma в репозиторий без участия человека.
  4. Метрика здоровья DS — процент детачей в Figma Library Analytics: если детачат >50% случаев, значит что-то сломано.
  5. DS = культура + договорённости: технический инструментарий масштабируется именно потому, что есть общее понимание ценностей.

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

Контекст

До редизайна приложение не обновлялось около пяти лет — накопленный долг по консистентности и UX. В процессе редизайна стали появляться неконсистентные элементы и паттерны — основной сигнал для создания DS. Спикер пришёл не с нуля: базовые наработки уже были, его задача — развивать и улучшать пользовательский опыт через систему.

Позиционирование и цели

В Dodo дизайн-система — это инструмент свободы, а не свод правил. Ценность: улучшение UX через консистентность + ускорение дизайна и разработки. Но не менее важна культура общих договорённостей: именно она масштабирует систему туда, куда технически ещё не добралась DS.

DS стоит ниже бренда в иерархии: бренд задаёт направление, DS распространяет его на уровне приложения. Интересный факт: редизайн приложения вышел раньше ребрендинга, и DS фактически задала некоторые константы бренду.

  1. Что DS делает:
  2. Компоненты для iOS и Android, токены, иконки, иллюстрации, чек-лист, документация, шоу-кейс, sandbox
  1. Что DS не делает:
  2. Продуктовые решения (за ними — продуктовые команды)
  3. Коммуникационные материалы (брендинг-дизайнеры)
  4. Веб — пока в разработке

Состав системы

  1. Что входит:
  2. Foundations: библиотека токенов (цвета, типографика, платформенные константы); моды платформ (iOS, Android, iOS 26)
  3. Компоненты: мастер-компоненты в отдельных файлах; документация для разработчиков — рядом с мастером
  4. Show Case: отдельный файл для дизайнеров — все компоненты, примеры использования, паттерны
  5. Sandbox: отдельное приложение на iOS и Android — живое тестирование компонентов
  6. Иконки: полностью автоматизированный экспорт из Figma (правильное название, размеры, форматы)
  7. Иллюстрации: в планах — такая же автоматизация, как с иконками
  8. Чек-лист (Figma Widget): встраивается в любой файл; переводы, RTL, corner cases, масштабирование
  9. Гайды: отдельный файл — как использовать сущности, как переделывать макеты под Android
  10. Автоматизация токенов: Figma → GitHub → xcassets (iOS) / XML (Android); собственная разработка
  1. Что в планах:
  2. Веб-версия DS
  3. Автоматизация экспорта иллюстраций
  4. Распространение DS на киоски

Процессы развития

Схема процесса (8 шагов):
1. Запрос от дизайнера или инициатива дизайнера DS
2. Оценка: небольшое — сразу в работу; большое — в бэклог
3. Разработка компонента с документацией
4. Ревью файла (дизайн-лит + дизайнер DS)
5. Передача разработке; еженедельный созвон с разработчиками
6. Разработка на iOS и Android (отдельные лиды)
7. Пометка статуса готовности (дизайн / iOS / Android)
8. Публикация в дайджесте (раз в 2 недели)

  1. Ритмы:
  2. Раз в неделю — дизайнеры показывают, над чем работают (открытый шеринг)
  3. Раз в неделю — созвон с разработчиками DS
  4. Раз в две недели — дайджест с новинками DS
  5. Раз в месяц — опрос дизайнеров о DS
  6. Раз в месяц — встреча по эмоциональному дизайну и культуре

Документация

  1. Что в доке есть:
  2. Анатомия компонента
  3. Состояния компонента
  4. Corner cases: длинные суммы, масштабирование шрифта до 310%, RTL
  5. Примеры использования и паттерны
  6. Правила верстки компонентов для разработчиков
  7. Статусы готовности (дизайн / iOS / Android)
  8. Гайды по сущностям в отдельном файле

Синхронизация дизайна и кода

  1. Автоматизация токенов: Figma → GitHub → xcassets (iOS) / XML light+dark (Android); собственная разработка без сторонних инструментов.
  2. Автоматизация иконок: новая/обновлённая иконка уходит с правильным именем, размером и форматом без участия разработчика.
  3. Моды платформ: переключение iOS/Android в один клик через переменные Figma — шрифты, цвета, компоненты меняются автоматически.
  4. DevMode: обязателен для всех разработчиков; проводились воркшопы по использованию.
  5. Figma MCP: эксперимент — автоматическая вёрстка UI-компонентов из Figma, разработчик добавляет логику.
  6. Sandbox: отдельное приложение на iOS и Android для дизайн-ревью компонентов вживую.

Контроль качества

  1. Защитные механизмы:
  2. Library Analytics в Figma — метрика детачей: если компонент детачают >50% случаев, значит что-то неудобно или сломано
  3. Ревью файлов: дизайн-лит смотрит пакеты к разработке; дизайнер DS проверяет, как используются компоненты
  4. Чек-лист (Figma Widget): переводы, RTL, corner cases, масштабирование, VoiceOver — прямо в рабочем файле
  5. Sandbox: физическое тестирование на устройствах
  6. Политика детача: детач разрешён при наличии гипотезы; успешный результат масштабируется на DS
  7. Опросы раз в месяц: сигналы о проблемах, которые дизайнеры не сообщают сами

Масштабирование и внедрение

Dodo — международная компания с приложением в арабских странах, Вьетнаме, СНГ и других рынках. Это напрямую влияет на DS: RTL-поддержка заложена во все новые компоненты, corner cases включают длинные числа в суммах (вьетнамский донг), масштабирование шрифта до 310%, VoiceOver.

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

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

Уникальные практики и «фишки» кейса

  1. Автопереключение платформы iOS → Android через моды токеновВ базовой библиотеке токенов зашиты платформенные константы. Переключение мода в Figma автоматически меняет шрифты, цвета и компоненты под Android. Макет для Android = копия iOS + смена мода. Без ручной переделки. «Мы просто копируем с iOS, вставляем на страницу с Android, и это всё автоматически перекрашивается.»

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

  3. Show Case vs мастер-файлы — разделение пространствShow Case — один файл для дизайнеров: все компоненты, примеры, паттерны. Мастер-компоненты с документацией для разработчиков — в отдельных файлах. Снижает когнитивную нагрузку для каждой аудитории.

  4. Library Analytics как метрика здоровья DSFigma показывает, сколько раз компонент был детачен за 30 дней. Высокий процент — сигнал проблемы, а не нарушение правил. Метрика использования компонентов как индикатор удобства.

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

  6. Чек-лист как Figma-виджетВстраивается прямо в рабочий файл. Обязательные пункты: переводы, RTL, corner cases (суммы в разных валютах), масштабирование шрифта, VoiceOver. Не отдельный документ, а часть рабочего процесса.

  7. RTL и локализация как часть компонентаПоддержка Right-to-Left заложена во все новые компоненты — включая направление иконок (в арабских интерфейсах стрелки меняют значение). Это стандарт при создании компонента, а не отдельный проект.

Выводы и принципы

  1. Что стоит попробовать другим:
  2. Моды платформ в токенах — если поддерживаете iOS и Android, один мод вместо двух параллельных наборов макетов.
  3. Library Analytics — проверять процент детачей регулярно; это честная метрика удобства компонентов.
  4. Разрешённый детач с гипотезой — убрать запрет на детач, добавить требование: детач = гипотеза с обоснованием.
  5. Чек-лист как Figma-виджет — встроить прямо в рабочий процесс, а не держать в отдельном документе.
  6. RTL и corner cases с самого начала — если есть хоть один международный рынок, закладывать в стандарт компонента.
  1. Ограничения:
  2. Разрешённый детач требует зрелой команды с пониманием гипотез — в хаотичной среде превратится в анархию.
  3. Автоматизация токенов/иконок — собственная разработка; требует технической экспертизы внутри команды DS.
  4. Один дизайнер на DS — высокий bus factor; при масштабировании нужна команда.

Кому подходит:
Продуктовые команды с небольшой командой DS; международные продукты с несколькими рынками; компании, где культура важнее регламентов; стартапы и mid-size с активными AB-тестами.

К следующему кейсу:
JSON Кросс-платформа
IVI DS
Перейти

По совету эксперта:

Термины из кейса:

AI-ревьюер

ИИ проверяет макет на соответствие правилам дизайн-системы.

BDUI (Backend-Driven UI)

Сервер отдаёт описание интерфейса (JSON), клиент его рендерит.

Хотите поделиться
своим кейсом?