От кроссплатформенного Flutter-продукта к Native iOS
Перестройка мобильного продукта, дизайн-системы и структуры Figma после перехода iOS с Flutter на нативную разработку. Android при этом продолжил развиваться на Flutter, поэтому задача заключалась не только в адаптации интерфейсов, но и в создании системы, позволяющей двум платформам развиваться параллельно как один продукт.
Перестройка мобильного продукта, дизайн-системы и структуры Figma после перехода iOS с Flutter на нативную разработку. Android при этом продолжил развиваться на Flutter, поэтому задача заключалась не только в адаптации интерфейсов, но и в создании системы, позволяющей двум платформам развиваться параллельно как один продукт.
Роль
Product / UI/UX Designer
Зона ответственности
Развитие продукта в дизайн-команде, Native iOS adaptation, адаптация iOS Design System под продукт, реструктуризация master screens и flows, компонентная система, Figma Slots, platform-specific states, handoff
Статус
В разработке
Платформы
Native iOS / Android Flutter / Web / Mobile Web
Diom
DIOM — социальная платформа, которая объединяет контентные и коммуникационные сценарии: вертикальные видео, ленту публикаций, сообщества, каналы и мессенджер. Отдельное направление продукта связано с инструментами монетизации для авторов.
Над продуктом работает небольшая дизайн-команда из трёх человек. Мы на равных развиваем существующие сценарии, проектируем новые функции и поддерживаем общую систему интерфейсов для mobile и web.
До технологического разделения мобильная версия проектировалась универсально для iOS и Android и реализовывалась на Flutter. По мере развития продукта стало понятно, что для iOS необходим отдельный нативный подход.
На публичной web-версии DIOM сейчас также обозначен как alpha-продукт и уже разделяет контент на несколько основных направлений, включая «Дропы», «Поток» и «Хаб».
Над продуктом работает небольшая дизайн-команда из трёх человек. Мы на равных развиваем существующие сценарии, проектируем новые функции и поддерживаем общую систему интерфейсов для mobile и web.
До технологического разделения мобильная версия проектировалась универсально для iOS и Android и реализовывалась на Flutter. По мере развития продукта стало понятно, что для iOS необходим отдельный нативный подход.
На публичной web-версии DIOM сейчас также обозначен как alpha-продукт и уже разделяет контент на несколько основных направлений, включая «Дропы», «Поток» и «Хаб».
Продуктовый контекст
Одна социальная платформа с несколькими сценариями взаимодействия
Изначально одна мобильная дизайн-система обслуживала сразу две платформы. Интерфейсы проектировались максимально универсально, а Android и iOS использовали одну Flutter-реализацию.
После работы с продуктом команда приняла решение перевести iOS на нативную разработку: это позволило корректнее использовать возможности системы и избежать части проблем, возникавших в кроссплатформенной реализации.
Android при этом остался на Flutter.
Android → Flutter
iOS → Native
Задачей дизайна стало не создать две независимые версии приложения, а сохранить единый продукт при разных правилах реализации.
После работы с продуктом команда приняла решение перевести iOS на нативную разработку: это позволило корректнее использовать возможности системы и избежать части проблем, возникавших в кроссплатформенной реализации.
Android при этом остался на Flutter.
Android → Flutter
iOS → Native
Задачей дизайна стало не создать две независимые версии приложения, а сохранить единый продукт при разных правилах реализации.
Почему одной Flutter-системы стало недостаточно
Технология изменилась — дизайн-процесс тоже должен был измениться
Я стала одной из дизайнеров, ведущих направление перехода на Native iOS.
Вместо прямого переноса существующих экранов мы начали использовать нативную iOS Design System как основу и адаптировать её под визуальный язык DIOM.
Для каждого паттерна нужно было определить, что:
сохраняет общую продуктовую логику → получает iOS-вариант → заменяется системным решением
Это затронуло компоненты, состояния, навигацию, sheets, menus, системные действия, формы, иконки и другие элементы интерфейса.
В результате iOS сохраняет узнаваемый язык DIOM, но перестаёт быть визуальной копией Android-версии и следует логике своей платформы.
Вместо прямого переноса существующих экранов мы начали использовать нативную iOS Design System как основу и адаптировать её под визуальный язык DIOM.
Для каждого паттерна нужно было определить, что:
сохраняет общую продуктовую логику → получает iOS-вариант → заменяется системным решением
Это затронуло компоненты, состояния, навигацию, sheets, menus, системные действия, формы, иконки и другие элементы интерфейса.
В результате iOS сохраняет узнаваемый язык DIOM, но перестаёт быть визуальной копией Android-версии и следует логике своей платформы.
Native iOS adaptation
Не копировать Flutter-интерфейс, а адаптировать продукт под iOS
После разделения платформ вместо одной универсальной мобильной системы стали сосуществовать две связанные системы.
DIOM Design Systemэ
Общие продуктовые принципы, визуальный язык, базовые сценарии и компоненты, на которых продолжают строиться Android и web-интерфейсы.
iOS × DIOM Design System
Нативные iOS-компоненты и системные паттерны, адаптированные под характер продукта.
Общими остаются назначение компонентов, продуктовая логика, контентная иерархия и ключевые сценарии. При этом визуальное и поведенческое исполнение может различаться в зависимости от платформы.
DIOM Design Systemэ
Общие продуктовые принципы, визуальный язык, базовые сценарии и компоненты, на которых продолжают строиться Android и web-интерфейсы.
iOS × DIOM Design System
Нативные iOS-компоненты и системные паттерны, адаптированные под характер продукта.
Общими остаются назначение компонентов, продуктовая логика, контентная иерархия и ключевые сценарии. При этом визуальное и поведенческое исполнение может различаться в зависимости от платформы.
Две дизайн-системы одного продукта
Diom Design System
Human Interface Guidelines ➔ Buttons
DIOM Design System + iOS × DIOM Design System
После перехода iOS на native прежняя организация макетов перестала масштабироваться.
Я переработала структуру файлов так, чтобы дизайнеры могли синхронно развивать продукт, а разные команды разработки получали только релевантные им платформенные сценарии.
Mobile App
Web
Отдельно существует:
Я переработала структуру файлов так, чтобы дизайнеры могли синхронно развивать продукт, а разные команды разработки получали только релевантные им платформенные сценарии.
Mobile App
- Master Screens App: Актуальные Android- и iOS-экраны расположены рядом и обновляются параллельно.
- Android Flows → Flutter development
- iOS Flows → Native iOS development
Web
Отдельно существует:
- Master Screens Web
- Web & Mobile Web Flows
Поиск, фильтры и карта
Один источник Master screen —
отдельные файлы для платформенных flows
отдельные файлы для платформенных flows
Переход стал поводом пересмотреть не только файлы, но и сам способ сборки интерфейсов.
По разработанному мной алгоритму master screens и связанные с ними макеты были последовательно пересобраны на компонентной архитектуре с использованием Slots в Figma.
Slots позволили создавать более гибкие master-компоненты: сохранять общую структуру экрана, но заменять отдельные функциональные области без создания большого количества почти одинаковых вариантов.
По разработанному мной алгоритму master screens и связанные с ними макеты были последовательно пересобраны на компонентной архитектуре с использованием Slots в Figma.
Slots позволили создавать более гибкие master-компоненты: сохранять общую структуру экрана, но заменять отдельные функциональные области без создания большого количества почти одинаковых вариантов.
Компонентная архитектура и Slots
Перестроить макеты так, чтобы изменения масштабировались на весь продукт
Переход на Native iOS потребовал изменить не только визуальное исполнение приложения, но и саму систему работы над продуктом.
В результате:
две дизайн-системы сохраняют общую продуктовую основу
master screens синхронизируют актуальное состояние платформ
отдельные flows учитывают различия iOS и Android development teams получают собственные структурированные файлы компоненты со Slots позволяют быстрее масштабировать новые сценарии.
Единый продукт — это не одинаковые интерфейсы. Это общая логика, которая корректно работает в контексте каждой платформы.
В результате:
- Android продолжает работать на Flutter
- iOS развивается на Native
две дизайн-системы сохраняют общую продуктовую основу
master screens синхронизируют актуальное состояние платформ
отдельные flows учитывают различия iOS и Android development teams получают собственные структурированные файлы компоненты со Slots позволяют быстрее масштабировать новые сценарии.
Единый продукт — это не одинаковые интерфейсы. Это общая логика, которая корректно работает в контексте каждой платформы.
Результат
Две платформы, которые можно развивать параллельно как один продукт
