IVI DS
Формат: кейс по публичным материалам (статьи + превьюер design.ivi.ru). Дата обращения: апрель 2026.
- Компания/продукт: ivi — российский онлайн-кинотеатр.
Главное
- Компания/продукт: ivi — российский онлайн-кинотеатр.
- Контекст платформ: iOS/Android/Web/Smart TV/Apple TV + email-рассылки.
- Уровень открытости: частично (публичные статьи + превьюер); код и Figma закрыты.
- Фокус кейса: как построить кросс-платформенную дизайн-систему там, где не работает «обычная» модель (CSS/React-компоненты/React Native).
Контекст
Контекст: задача без готового решения
IVI работает на принципиально разных платформах: мобильные устройства, веб, Smart TV с устаревшими браузерами и даже email-верстка. В такой среде не подходит распространённая стратегия «одна библиотека компонентов/стилей на всё». Ограничения платформ напрямую влияют на архитектуру дизайн-системы: на Smart TV недоступен современный CSS, email требует табличной вёрстки, а iOS/Android остаются нативными SDK.
Состав системы
Архитектура: примитивы, компоненты и модульная сетка
3.1 Два типа сущностей
В IVI DS разделены два вида сущностей. Примитивы (цвет, прозрачность, типографика) — это данные без визуального воплощения. Компоненты (кнопка, постер, виджет) — описанные сущности с внешним видом, состояниями и модификаторами (размеры, цветовые вариации). Такое разделение делает систему расширяемой: примитивы можно менять независимо, а компоненты опираются на них как на базу.
3.2 Модульная сетка вместо медиазапросов
Для адаптивности используется модульная сетка: экран делится на колонки, и для каждого количества колонок задаётся свой макет. Это решает задачу адаптивности без reliance на CSS media queries — что критично для платформ, где современный CSS недоступен.
3.3 iviUIKit на iOS как слой компоновки
В iOS-контуре используется iviUIKit, который предлагает две базовые модели компоновки: свободную компоновку элементов и компоновку коллекций. Поверх нативных констрейнтов добавляются синтаксические конструкции в терминах колонок. Архитектурно взаимодействие сосредоточено во View (VIPER-архитектура).
Процессы развития
Управление изменениями: deprecation на уровне данных
Редкая для рынка практика — механизм устаревания встроен в сам формат данных. Система умеет сообщать разработчикам, какие свойства или компоненты нельзя использовать, и удалять их только тогда, когда они перестают использоваться на всех платформах. Это делает deprecation синхронизированным между iOS/Android/Web/TV/email, а не «локальной» историей одной команды.
Уникальные практики и «фишки» кейса
Уникальные практики (в логике исследования)
- JSON как универсальный стандарт для iOS/Android/Web/Smart TV/email — инженерная альтернатива CSS/React Native.
- Превьюер как платформа DS: витрина построена на том же источнике правды, что и продукт.
- Автогенерация документации из данных (HTML + JSON) + ручное уточнение текста.
- Deprecation в формате данных: единый механизм устаревания для всех платформ.
- Модульная сетка как способ адаптивности без CSS media queries (важно для устаревших клиентов).
Выводы и принципы
Ограничения кейса
- Часть материалов датирована 2021 годом — текущее состояние системы полностью не видно.
- Кодовая реализация, Figma-библиотеки и детализация токенной системы закрыты.
- Формат данных с 2018 года описан как «плоский список свойств» без явной типизации и перечня состояний — это усложняет дальнейшую автоматизацию.
Источники
- habr.com/ru/companies/ivi/articles/565500/ — «IVI DS. Взгляд изнутри. Часть 1» (2021)
- habr.com/ru/companies/ivi/articles/565516/ — «IVI DS. Взгляд изнутри. Часть 2» (2021)
- vc.ru/design/72354 — «От UI-kit до дизайн-системы. Опыт ivi»
- design.ivi.ru — публичный превьюер компонентов
«Поэтому для нас не подходит распространённая схема — поставлять готовые CSS-стили или React-компоненты.»