SDUI. Создание дизайн-платформы для мобильного приложения ВкусВилл.

В индустрии наблюдается тренд на SDUI. Многие компании оптимизируют разработку, стремясь делать часть изменений безрелизными. Во «ВкусВилл» также искали решение по управлению контентом приложения с сервера. Я присоединился к компании в январе 2023 года, и передо мной стояли задачи по улучшению процессов в дизайне, включая внедрение новых технологий и оптимизацию рабочих процессов. Решая эти вопросы, я познакомился с разработчиками из «Автомакона» — компании, которая отвечает за работу нашего приложения. Вместе с ними мы создали новую команду и начали, пожалуй, самый амбициозный внутренний проект.

Привет, я Сергей Мухин, арт-директор онлайн-направления во «ВкусВилл». Я расскажу, как мы пришли к необходимости создания собственной SDUI платформы для мобильных приложений, разработки собственных инструментов для дизайнеров, с какими вызовами мы столкнулись и что у нас получилось.

Начало

Одной из проблем, с которой я впервые обратился к разработчикам, было внедрение дизайн-токенов. В приложении и на сайте остро стоял вопрос согласованности цветов, текстовых стилей и визуальных элементов в целом.
Различия некоторых цветов в МП и на сайте.
На тот момент цвета мобильного приложения и сайта вроде в общем и следовали брендбуку ВкусВилл, но отличались в деталях между платформами.

Я сделал новые цветовые растяжки, используя colorbox.io. Основываясь на цветовой модели HSB, я взял только оттенки (hue) из брендбука, полностью пересчитав насыщенность (saturation) и яркость (brightness), и получил референсную палитру. В ней растяжки шли от основного цвета к белому и черному. Для каждого оттенка я сделал два набора токенов: с нормальной и пониженной насыщенностью, а также два набора оттенков серого со сплошными и прозрачными вариантами.

Референсная палитра. Это база для всех последующих вариантов семантических палитр.

Затем на основе этой палитры я создал второй уровень цветовых токенов — семантический. Структура семантической палитры напоминала Material Design и была организована по группам.

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

Я взял принцип организации оттенков серого и разложил его на другие цвета, регулируя также «акцентность», заодно сделав и инверсию. Получились своеобразные модули по каждому из оттенков.
Эти модули назвали «контекстами», и у всех них названия токенов полностью совпадали. Цветовая семантика выглядела так: имя-темы.имя-контекста.название-цвета.
Уже тогда была идея привязать имя контекста к свойству и наделить им все виджеты, сделав это свойство наследуемым. Таким образом, при переключении контекста у, например, острова, все внутренние элементы также меняли бы цвет, наследуя контекст от родительского виджета.

Пример виджета с использованием контекстов
Я сделал вот такой прототип, для того чтобы наглядно показать и объяснить принцип работы контекстов команде.

С этими идеями я собрал встречу с командой разработчиков. Они с интересом восприняли все мои предложения. Однако вариант с контекстами оказался нереализуем в текущей архитектуре приложения. На фронте невозможно сделать 3 уровня цвета и подменять среднюю часть через свойство. Фронт может работать только с классической семантикой имя-темы.название-цвета.

Поэтому для текущего приложения мы выбрали первый вариант семантики с разделением на поверхности, акцентные цвета и контейнеры. Далее оказалось, что реализация контекстов всё же возможна, но на сервере. Если приложение будет работать по принципу SDUI (server driver UI), то контексты и многое другое можно будет осуществить. И тут выяснилось, что у разработчиков уже давно существует собственный проект SDUI архитектуры! Команда энтузиастов уже довольно долго работала над решением основных проблем разработчиков и переносом всей бизнес-логики на сервер. Мы решили обменяться идеями и посмотреть, как это всё можно объединить.

Формирование концепции

То, что разработчики уже работали над SDUI архитектурой, оказалось большой удачей и приятной неожиданностью. Однако предстояло ещё много работы, чтобы концепция обрела форму. Изначальный проект был сделан разработчиками для разработчиков, и вопросы дизайна и дизайн-системы практически не прорабатывались. Верстка виджетов хранилась на клиенте, а сервер управлял только их положением и параметрами. Мне же хотелось добиться полной управляемости верстки с сервера, сохраняя приложение нативным.

Чтобы понять, насколько это амбициозная задача, можно найти в сети видео и статьи об опыте других компаний по внедрению SDUI. Чаще всего количество виджетов в таких системах оставалось четко предопределенным. Были, конечно, эксперименты со слотами, когда внутри одних компонентов есть «ячейки», куда можно вставлять другие компоненты и управлять этим с сервера. Это сопровождалось внушительным списком параметров. Но всё равно рамки оставались жёсткими: любое расширение требовало доработки клиента, повышения версии приложения и релиза в магазин приложений.

Основными преградами на пути к желаемой степени вариативности и управляемости чаще всего становились производительность и скорость отрисовки.

Битва за миллисекунды

Чтобы понять, почему производительность для SDUI приложения это на столько серьезная проблема, нужно разобраться, что такое SDUI.

Что такое SDUI и контракт

Ключевое отличие SDUI от традиционного подхода — в «тупом» клиенте (т.е. приложении. А вы что подумали?). Что это значит? Представьте, что у вас есть чекбокс. В SDUI клиенте нажатие на него не переключает его в состояние checked, а просто отправляет на сервер событие «ой, на меня нажали» и ID самого чекбокса. А дальше, если нужно, сервер пришлет новую верстку, где чекбокс уже будет включен.
Схема обмена данными в SDUI.
Делается это через контракт — JSON или XML документ с деревом объектов и их параметров. В консервативном виде, с конечным списком виджетов на клиенте, контракт выглядит примерно как на рисунке ниже.
Пример консервативного контракта кнопки.
В примере видно, что можно управлять цветом кнопки, иконкой и текстом. Но радикально изменить структуру не получится. Например, нельзя добавить второй блок текста в кнопку, скажем, подзаголовок, или изменить верстку так, чтобы иконка была по центру сверху над текстом. Такие изменения потребуют доработки клиента и повышения версии приложения.

Мы же стремились к более детальному управлению версткой, и, забегая вперед, у нас получился вот такой контракт:
Пример нашего контракта кнопки
Здесь уже иконка и текст, это не просто параметры виджета кнопки, а объекты внутри него со своими параметрами, их можно менять местами, добавлять больше вложенных объектов, в общем вариативность возросла в несколько раз, но и объем контракта тоже.

Почему размер контракта — это проблема? Во-первых, его нужно переслать с сервера на клиент по сети, и здесь может возникнуть задержка. Далее, достаточно объемный тестовый файл нужно конвертировать в верстку на клиенте и отрисовать. После этого необходимо отслеживать изменения, и, скажем, при изменении внешнего вида элемента, прислать новый контракт и заново его отрисовать. В итоге, если всё сделать максимально прямолинейно, пользователь будет, в лучшем случае, видеть мерцания, а в худшем — загрузку после каждого действия. Нужно было искать более хитрые решения и подход.

Значения по умолчанию

Это самый простой и достаточно очевидный способ сократить контракт. Каждому параметру виджета задать значение по умолчанию, и если параметр не пришел в контракте, устанавливать ему это значение.

Наследуемые свойства

У меня уже была концепция Контекстов, о которой я писал выше. Она должна была работать следующим образом:


  • Если в свойстве context у виджета указано не конкретное значение, а inherit (то есть унаследовать), то отрисовщик на клиенте поднимался вверх по дереву объектов, пока не находил нужное значение. Корневым всегда являлся виджет экрана (ScreenContainer), у которого в свойстве контекста всегда было значение, и оно не могло быть inherit.
  • Если же у виджета в свойстве контекста было значение, то начиналась его собственная линия наследования контекста.

Схема наследования контекста

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

Такая механика уже обеспечивала довольно хороший контроль над внешним видом виджетов с помощью всего одного параметра. Поскольку обработка механизма наследования происходила на стороне клиента, в контракте требовалось прислать лишь токен цвета и его контекст.
Однако для окончательного решения проблемы со скоростью отрисовки контрактов нужен был последний штрих.

Наследуемая активность

В дополнение к контекстам я решил сделать наследуемое свойство active. Мы долго обсуждали название свойства, потому что в вебе уже есть понятие active (псевдокласс) отвечающее за состояние при нажатии, но ничего лучше не смогли придумать, по этому оставили так, и договорились не путать.
Свойство «active» имело допустимые значения «true» и «false» и могло наследоваться от родительского виджета к дочернему.

По сути, это была абстрактная «активность». Трактовать её можно было очень по-разному. Например, активным мог считаться чекбокс, выбранная вкладка или кнопка уведомлений с индикатором о том, что есть новые уведомления.

Пример того, как может применяться свойство Active.

Просто переключив одно свойство можно было изменить внешний вид всего виджета.
Затем нужно было связать контексты и активность, для этого отлично подошли парные свойства. Цвета текста и фона стали двойными, например, «default-background» и «active-background». Двойным стал и контекст, разделившись на «active-context» и «default-context».

Теперь, привязывая другие свойства и, самое главное, контекст к активности виджета, можно было управлять внешним видом интерфейса, передавая всего пару параметров.
Механика наследуемых свойств предоставляла широкие возможности для управления вёрсткой, открывая путь к желаемой вариативности. Теперь предстояло «продать» всю концепцию продуктовым командам.
Гипотеза ценности
Онлайн-подразделение «ВкусВилл» совсем молодое, и приложение ещё недавно стартовало как стартап. Но уже сегодня им ежедневно пользуется более 1 миллиона пользователей. Такая колоссальная ответственность требует тщательной подготовки новых обновлений и работы над стабильностью. Это обуславливает очень длинный жизненный цикл задач и большое количество трудностей на пути вывода функционала на прод.

Всё усложняется тем, что почти любые изменения публикуются через магазин приложений, в том числе исправления багов. Это делает тестирование ещё более ответственным и трудоёмким, а также повышает цену ошибки.

В компании уже вели работы по управлению интерфейсом с сервера, изменению порядка виджетов и их параметров. Однако бизнес-логика оставалась на стороне клиента, а сам процесс разработки, начинающийся с дизайна, сохранял классическую структуру с параллельной разработкой для iOS и Android и всегда завершался обновлением в магазине приложений.
Схема текущего процесса delivery
Мы же с командой к тому моменту достигли значительных успехов в управлении вёрсткой и предложили не просто SDUI, но и автоматизацию переноса дизайна из Figma на сторону клиента. Это позволило бы разрабатывать продукт один раз, без необходимости адаптации под разные платформы.
Новая схема, которую обещала наша платформа.
Подобное упрощение процесса позволило бы сократить TTM (time to market) в несколько раз и значительно сэкономить ресурсы разработчиков. Кроме того, оно привело бы к улучшению качества реализации дизайна и повышению стабильности приложения в целом, поскольку теперь требовалось бы проводить тестирование вдвое меньше.

Такое смелое обещание произвело впечатление на команды, и проект получил зеленый свет. Но почему мы были так уверены, и как это работает?
Новая атомарность
Мы решили зайти дальше привычных кнопок и полей ввода, и разбить всё на супер мелкие элементы, мы по началу называли их примитивами, затем дали названия Items этой группе виджетов.

Да, сразу нужно договориться о терминах. В нашей системе мы придерживаемся подхода «all is widget», потому виджетом называем любой элемент платформы.
Так что это были за примитивы.
Вывод текста, иконки и ввод текста. Причём ввод текста представлен не в виде привычного поля, а как полоса без фона с мигающим курсором.

Даже такой элемент, как свитчер (переключатель), который на первый взгляд кажется привычным, отличался от того, каким он представлен в HIG или MUI.

Пример того, как может применяться свойство Active.
В нашем случае это был не полноценный элемент управления, который умеет переключать собственные состояния по нажатию, а просто «рисунок свитчера», который требовалось как бы «обернуть в интерактивность», чтобы он начал работать привычным образом.

Стоит отметить, что, несмотря на такой подход, примитивы оставались полностью платформенными, а метод рендеринга — аппаратным, то есть приложение оставалось полностью нативным.

WidgetWrapper

Чтобы всё разнообразие Item’ов заработало, нам нужен был контейнер. Или, может быть, контейнеры?
Сначала мы рассматривали узкоспециализированные «обёртки», например, composer + decorator. Первый отвечает за вёрстку элементов внутри себя, второй — за фон, обводку, тени, в общем, оформление.
Но довольно быстро мы пришли к выводу, что нужен универсальный контейнер, который будет уметь всё. И мы назвали его WidgetWrapper.
Схематичное изображение того, как из врапперов строится интерфейс.
Помимо уже упомянутых декоратора и композера, во враппер также вошло управление интерактивностью. Она может быть следующих типов:
  • static —без взаимодействия;
  • press («нажми меня») — делает из враппера кнопку;
  • check («выбери меня») — логика работы как в чекбоксе;
  • radio («выбор одного из группы») — для реализации виджетов с логикой как у радиокнопки.

Check и radio автоматически переключают active у враппера в противоположное значение ещё до запроса на сервер, что делает взаимодействие плавным.
В целом по своей сути WW очень напоминает фрейм в фигме или <div> в вебе.

Пресеты

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

Локальные пресеты (на клиенте)

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

Серверные пресеты

Примеры пресетов на сервере.
Эта категория пресетов позволяет решить сразу несколько задач:
  • обеспечить ещё более глубокое кеширование для ускорения работы и повышения скорости отрисовки часто используемых элементов;
  • повторно использовать типовые элементы интерфейса;
  • менять состояния там, где недостаточно наследуемых свойств и возможностей врапперов.
Серверные пресеты хранятся отдельно, имеют различные состояния и подвергаются отдельному кешированию. Состояния представляют собой именно вариации разных шаблонов вёрстки, а не просто разные способы оформления или отличия в текстах.

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

Кстати, выше на примере видно, что в фигме у каждого компонента у нас довольно не много вариантов. Почти всё поведение реализуется платформой, поэтому нет необходимости прорисовывать состояния нажатия, disable и т. д. Всё будет сделано автоматически. А за свойство disable и вовсе отвечает специальный контекст, который при значении свойства disable=true применяется автоматически к виджету и всем его дочерним элементам, и делает их визуально неактивными.

Контекст Inactive служит для реализации свойства disable=true

Из фигмы сразу на прод. Автоматизация
Макет, андроид, iOS. Автоматически выгруженная верстка.
Придумать, как быстро и точно отрисовать контракт на клиенте — это, конечно, здорово, но оставался ещё handoff— этап передачи макета от дизайнера к рарзаботчику и его преобразование в контракт.

Я уже говорил, что наш WidgetWrapper по своей сути очень похож на фрейм в фигме. Более того, сами файлы макетов фигмы хранятся в JSON, а у нас в этом формате как раз делается контракт.

Решение было очевидным: автоматически преобразовать JSON макета в наш формат.

Цена автоматизации: дизайнер должен страдать.

Благодаря автоматизации дизайнеры получили полный контроль над визуалом и теперь могут сразу выгружать макет в JSON уже свёрстанным. Это практически исключило участие человека в процессе передачи. Но есть и обратная сторона медали: дизайнеры стали страдать.

Служебные слои

Враппер, конечно, похож на фрейм, но у него есть ряд нюансов, которых в стандартных свойствах Фигмы нет. Нужно как-то указать в макете контекст и активность, чтобы автоматика могла их распознать. Про парные (активные и дефолтные) фон и обводку я вообще молчу.

Сначала мы хотели создать компонент враппера в Фигме, нашпиговать его пропсами и менять контент через swap instance. Но тут возникла проблема: компонент в Фигме не может быть вложен сам в себя. Можно сделать компонент с плейсхолдером внутри и в макете заменять его на другой компонент. Но нельзя в компоненте враппера заменить плейсхолдер на тот же враппер. Это называется рекурсивная вложенность, и её не поддерживают компоненты в Фигме, а ведь именно так должен работать враппер.

Единственное решение, которое мы смогли придумать и которое реально работает, — это служебные слои.

Служебные слои WidgetWrapper’а в фигме и все параметры слоя wrapper-settings

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

У этого подхода есть серьёзный минус: некоторые свойства нужно указывать сначала там, откуда они передаются в автоматику, а потом воспроизводить их визуально. Например, контексты задаются вручную в соответствующем поле. Дизайнер вписывает название нужного контекста, а потом применяет соответствующие стили в Фигме, чтобы макет визуально соответствовал тому, как это распознает автоматика. Дизайнеры научились довольно быстро с этим работать, и это практически нас не замедляет, но всё же порождает дополнительные неточности. легко можно не заметить, что где-то указано неверное свойство, и обнаружить ошибку только после рендера макета в тестовом приложении.

Исключения

Как будто нам мало всех заморочек со слоями, мы ещё обнаружили, что даже некоторые нативные свойства Фигмы на платформах работают иначе.
Различия в рендере внутренних отступов в фигме и на платформах
Например, в примере видно, как по-разному рендерятся внутренние отступы. В Фигме они просто сдвигают контент, а на платформах паддинги его «клипуют», то есть обрезают.

И таких исключений целый набор. Например, констрейнты тоже работают по-другому. На платформе нельзя указать смещение объекта с фиксированным положением: если у него констрейнт top-left, он будет притянут строго к верхнему левому углу контейнера. Чтобы сделать отступы от края, нужно дополнительно оборачивать объект во враппер и регулировать смещение паддингами.

Исключения

Например, в примере видно, как по-разному рендерятся внутренние отступы. В Фигме они просто сдвигают контент, а на платформах паддинги его «клипуют», то есть обрезают.

И таких исключений целый набор. Например, констрейнты тоже работают по-другому. На платформе нельзя указать смещение объекта с фиксированным положением: если у него констрейнт top-left, он будет притянут строго к верхнему левому углу контейнера. Чтобы сделать отступы от края, нужно дополнительно оборачивать объект во враппер и регулировать смещение паддингами.

Как выглядит управляющий файл (export list) в фигме

Автоматическая выгрузка шаблонов делается через специальный конвертер. Чтобы он не обрабатывал лишние данные в Figma, мы создали специальный файл — export list. В нём содержится список всего, что нужно экспортировать: шаблоны экранов, пресеты. Затем в этом файле на странице с названием Master мы собираем всё, что нужно экспортировать, и присваиваем им идентификаторы:

  • export-id — идентификатор шаблона, под которым будет выгружен JSON верстки шаблона;
  • state-id — поле для пресетов с несколькими вариантами или состояниями;
  • tag — поле, по которому элемент на фронте сопоставляется с бизнес-логикой на бэке.

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

Баги

Ну, а завершает парад жести для наших дизайнеров — баги Фигмы. Причём глючат и старые, и новые фичи, и совсем свежие variables, и базовые вещи, которые в Фигме есть с начала начал. Например, чтобы у фрейма было два фона, пришлось использовать приёмы, за которые в приличных командах сейчас бьют по рукам: вставлять прямоугольники в фон фрейма, подгонять их под размер и выставлять растяжение Scale по обеим осям или left-right и top-bottom, чтобы они изменяли размер вместе с родительским фреймом. Но эти прямоугольники ведут себя непредсказуемо и иногда самопроизвольно уезжают в случайные направления.
Фрагменты документации WidgetWrapper’а.
Чтобы улучшить работу с этим множеством нюансов, мы сделали подробную документацию с видео-примерами решения наиболее частых проблем прямо в фигме.

Это не решило все наши боли, но хотя бы сделало работу приемлемой. Однако это натолкнуло нас на определённые мысли. Забегая вперёд, мы нашли абсолютное решение всех бед, но об этом я расскажу в самом конце истории.
Proof of concept. Тех-демо и MVP.
Все наши обещания, гипотезы и смелые заявления нужно было проверить. Мы сделали это в два этапа.


Тех-демо

Сначала мы провели техническое демо, чтобы показать работоспособность технологии и подтвердить, что мы действительно можем создавать интерфейс, который по отклику не отличается от нативного, и при этом детально управлять им прямо из Figma.

Для этого нам потребовалось реализовать основные платформенные механики (например, наследуемые свойства, токены), но без пресетов, и минимальный набор виджетов: WidgetWrapper, IconBox, TexBox, ScreenContainer.

Этот скромный набор виджетов позволил нам собрать из них внушительный набор UI-элементов и собрать показательное демо-приложение.

На это нам потребовалось около трех месяцев.

Наше первое демо-приложение

Оптимизация отрисовки стала вызовом.

Мы использовали механизмы кеширования и наследуемые свойства, но этого оказалось недостаточно. Наши врапперы реализованы как View, или «вьюшки» — платформенные контейнеры. В традиционной вёрстке их обычно немного, а на простых экранах может быть и вовсе одна вьюшка. У нас же каждый враппер — это отдельный view. Но спустя много часов оптимизации мы всё же добились целевых показателей скорости отрисовки.

Наступил демо-день

Мы собрали команды, стейкхолдеров, подуктовых менеджеров, и всех, кому был интересен проект, предоставили всем желающим доступ к Test flight и сборке для Android и начали демонстрацию.

В начале встречи мы попросили всех открыть демо-приложение и поделиться впечатлениями. Затем я открыл Figma и начал менять макет, объясняя, как работает процесс. После этого слово взяли разработчики, и все ненадолго отвлеклись от демо-приложения. Но вскоре мы попросили всех ещё раз взглянуть на экраны своих телефонов, где уже были видны все изменения, которые я только что внёс в макет на глазах у коллег.

В результате никто не заметил никаких задержек или отличий от нативного приложения. Ведь мы добились отклика около 60 миллисекунд. И доказали, что наше приложение остаётся быстрым и плавным, даже когда нужно отрисовать сложный контракт. А когда интерфейс приложения поменялся вслед за макетом прямо у них в руках, это был настоящий wow-эффект.

MVP (minimum viable product)

Далее мы решили взять часть реального приложения ВкусВилл, сделать её полностью на SDUI, интегрировать в текущее мобильное приложение и протестировать на пользователях.
С помощью MVP мы хотим:
  • провести нагрузочные тесты, протестировать роутер, который распределяет сессии клиентов приложений по серверам;
  • понять, как это влияет на пользовательский опыт;
  • определить, зависит ли это от качества связи;
  • сравнить с текущим приложением и понять, не проигрываем ли мы ему;
  • выбрать путь внедрения SDUI: постепенно, частями или полностью новое приложение;
  • оценить скорость внедрения функций и исправления багов, сравнить с текущим приложением.
Для начала мы выбрали самую простую и понятную часть приложения — вкладку «Поддержка».

Главный экран раздела “Поддержка” в текущем приложении, сделанный на SDUI.
На момент написания этого текста мы тестируем проект среди сотрудников. На путь от тех-демо до релиза MVP ушёл примерно год. И хотя впереди ещё много работы, часть гипотез мы уже проверили и сделали выводы. Например, мы точно знаем, что не будем внедрять SDUI в приложение постепенно, потому что это очень трудоёмкий процесс, и большинство ошибок возникает именно на этапе интеграции. Осталось дождаться всех данных по итогам MVP, чтобы приступить к полноценному внедрению.
Собственная фигма. Редактор верстки.
Когда я рассказывал о работе в Figma и проблемах с автоматизацией, я упомянул, что мы нашли решение всех этих проблем.

Им стал собственный редактор, который позволяет редактировать файлы экранов и пресетов в нужном нам формате. Несмотря на название, редактор не заменит Figmu, а дополнит её.

Figma останется инструментом прототипирования, который будет использоваться для создания концептов, проведения исследований и discovery. В редактор можно будет импортировать макеты и доводить их до нужных кондиций без лишних сложностей, добавляя все необходимые свойства.

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

Файловый менеджер редактора
На скриншотах показан работающий редактор. Уже совсем скоро, всего через пару месяцев, мы начнём тестировать его вместе с командой продуктовых дизайнеров. И наконец нашим дизайнерам больше не придётся мучиться с SDUI в фигме.
Что дальше
В ближайшее время нам предстоит собрать данные по результатам тестирования MVP и подтвердить наши обещания по ускорению разработки и переходу к безрелизному процессу с помощью конкретных метрик. Например, в рамках одного из тестов мы планируем синхронно разработать одну из фичей совместно с командой текущего приложения, чтобы затем сравнить затраченное время и стабильность при тестировании.

Бизнесу нужно взвесить все преимущества и возможности технологии, а также риски и сложность внедрения, провести оценку полученного результата.

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

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

Написать мне:
Мой канал в Телеграме:

Made on
Tilda