Ozon — дизайн-система как продуктовая инфраструктура: несколько DS, процессы и Backend‑Driven UI

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

Главное

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

Фокус: многосистемность (несколько дизайн-систем под разные контуры), токены как «источник правды» в JSON, процессы и роли, контекстные команды «стандартов», архитектура Backend‑Driven UI (контракты/атомы/виджеты), измерение удовлетворённости (CSI).

Контекст: дизайн-система начиналась как инициатива дизайнеров для внутренних продуктов; затем бизнес увидел выгоду.

Контекст

Контекст: как появилась дизайн-система в Ozon

История запуска начинается с инициативы дизайнеров: изначально UI‑kit создавался не для клиентского приложения/сайта, а для внутренних продуктов. Далее «выгоду» почувствовал бизнес, и направление стало масштабироваться.

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

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

2. Цели: в первую очередь cost/time‑to‑market, а не бренд‑консистентность

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

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

Архитектура: несколько дизайн-систем и разные технологические стеки

Ozon работает не с одной «универсальной» дизайн-системой: выделяются отдельные контуры (например, клиентский покупатель, продавец, внутренние продукты), а также отдельные технологические стеки под платформы. Отдельно проговаривается, что мобильная дизайн-система переезжала на новые технологии (например, SwiftUI и Compose), а на вебе используются разные фреймворки в зависимости от контура.

Токены и темы: JSON как источник истины + кор‑палитра и семантика

Токенная инфраструктура описывается как строго инженерная: «главная точка» — JSON. В случае расхождений приоритет отдаётся токенам в кодовом представлении, а не дизайну в Figma. При этом используется общая кор‑палитра (растяжки оттенков), а над ней — семантические палитры для отдельных дизайн-систем. Темизация через переменные рассматривается как базовая необходимость для покрытия большого количества кейсов.

Роли и оргструктура: команда дизайн-систем + команды «стандартов»

Кейс подчёркивает организационную особенность: между продуктом и дизайн-системой есть отдельные команды «стандартов». Они консолидируют запросы продуктовых дизайнеров, берут ответственность за гайдлайны и отвечают на вопрос «как использовать компоненты». Дизайн-система при этом отвечает за вопрос «что делает компонент» и за текст‑спеки/техническую часть, привязанную к компоненту. Такое разделение снижает риск оторванности DS‑команды от продуктового контекста.

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

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

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

Процессы запросов и приоритизация: дизайн-система «от потребителей»

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

Коммуникации и вовлечение: Q&A‑встречи, демо и CSI‑опросы

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

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

Контроль качества и риски: legacy, неправильное использование токенов и перфоманс

Один из типовых рисков в масштабе — наследие и некорректное использование токенов продуктами. При попытке крупных изменений могут всплывать рассинхроны: продукты использовали токены не по правилам, и тема/перекраска «не сходится», что требует ручного разбора. Отдельный продуктовый фактор — производительность: в e‑commerce задержка загрузки экрана быстро конвертируется в потери.

ИИ и будущее: ускорение производства и риск «ИИ ради галочки»

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

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

Эволюция границ: слияния и разделения дизайн‑систем

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

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

1. Backend-Driven UI и «атомы»В клиентском контуре экран не собирается вручную из компонентов — приходит с бэка как набор виджетов. Компонент сам по себе не конечная сущность: связка «компонент + контракт» называется атомом, виджеты собираются из атомов. Даёт гибкость и приближает к «безрелизным» обновлениям в больших потоках A/B.

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

3. Трёхслойная палитра: кор → семантика → компонентОбщая кор-палитра с растяжками оттенков — поверх неё семантические палитры для каждой из нескольких DS — поверх них компонентный уровень. Одни и те же оттенки, но разный «язык» на каждом уровне: пересобирать бренд можно не трогая базу.

4. Команды «стандартов» как прослойка между продуктом и DSМежду продуктовыми дизайнерами и командой DS работают отдельные команды стандартов. Они консолидируют запросы, отвечают на вопрос «как использовать компоненты», пишут гайдлайны. DS-команда отвечает только за «что делает компонент» — без них быстро уходит из продуктового контекста.

5. Несколько DS вместо «одной на всё»Ozon сознательно держит разные DS под разные контуры: клиентский покупатель, продавец, внутренние продукты. Каждая под свой стек (SwiftUI/Compose, разные веб-фреймворки). Проект UNI — объединение мобильных DS — большой и сложный именно потому, что исторически систем несколько.

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

7. Q&A-встречи и демо как отдельный канал коммуникацииРегулярные встречи «вопросы и ответы» + демо новых компонентов делают DS-команду видимой, снижают нагрузку на чат поддержки и дают продуктовым дизайнерам канал влияния на роадмап.

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

Что можно перенять другим командам