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

IVI DS

Формат: кейс по публичным материалам (статьи + превьюер design.ivi.ru). Дата обращения: апрель 2026.

  1. Компания/продукт: ivi — российский онлайн-кинотеатр.

Главное

  1. Компания/продукт: ivi — российский онлайн-кинотеатр.
  2. Контекст платформ: iOS/Android/Web/Smart TV/Apple TV + email-рассылки.
  3. Уровень открытости: частично (публичные статьи + превьюер); код и Figma закрыты.
  4. Фокус кейса: как построить кросс-платформенную дизайн-систему там, где не работает «обычная» модель (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, а не «локальной» историей одной команды.

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

Уникальные практики (в логике исследования)

  1. JSON как универсальный стандарт для iOS/Android/Web/Smart TV/email — инженерная альтернатива CSS/React Native.
  2. Превьюер как платформа DS: витрина построена на том же источнике правды, что и продукт.
  3. Автогенерация документации из данных (HTML + JSON) + ручное уточнение текста.
  4. Deprecation в формате данных: единый механизм устаревания для всех платформ.
  5. Модульная сетка как способ адаптивности без CSS media queries (важно для устаревших клиентов).

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

Ограничения кейса

  1. Часть материалов датирована 2021 годом — текущее состояние системы полностью не видно.
  2. Кодовая реализация, Figma-библиотеки и детализация токенной системы закрыты.
  3. Формат данных с 2018 года описан как «плоский список свойств» без явной типизации и перечня состояний — это усложняет дальнейшую автоматизацию.

Источники

  1. habr.com/ru/companies/ivi/articles/565500/ — «IVI DS. Взгляд изнутри. Часть 1» (2021)
  2. habr.com/ru/companies/ivi/articles/565516/ — «IVI DS. Взгляд изнутри. Часть 2» (2021)
  3. vc.ru/design/72354 — «От UI-kit до дизайн-системы. Опыт ivi»
  4. design.ivi.ru — публичный превьюер компонентов

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