Преодоление разрыва между дизайном и кодом

«Дизайн и код» - это серия о проектных и инженерных экспериментах, процессах и знаниях, представленная вам командой AirSwap.

В AirSwap у нас есть асинхронный и итеративный подход к разработке продукта. Тем не менее, одной из самых ранних проблем, с которыми мы столкнулись, было поддержание единообразного идентификатора продукта с помощью итераций работы функций для нескольких владельцев продукта. Работая над ранними версиями AirSwap Token Trader и AirSwap Widget, мы быстро собрали несколько файлов Sketch - каждый файл содержал набор символов и стилей, которые представляли состояние нашего продукта на тот момент времени. Хотя это сработало в начале, отсутствие единого источника правды быстро переросло в беспорядок устаревших стилей в разных источниках.

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

Каждый интерфейс в AirSwap написан на React. В начале у нас был каталог общих компонентов, если хотите, предварительная библиотека компонентов, с надлежащими стилями, которые соответствовали бы идентичности продукта. Однако, поскольку мы повторили, идентичность нашего продукта изменилась. Ссылка на проектные компоновки для более новых функций усложнила определение того, существует ли конкретный компонент или его необходимо реализовать. Мы рано приняли решение использовать стилевые компоненты, что позволило нам быстро выполнять итерации и создавать функции. Простота использования со стилевыми компонентами была огромной победой, но она также непреднамеренно позволила нам принять некоторые плохие решения в расширении стилей. Без строгих правил о том, как создавать или расширять компоненты, наша кодовая база быстро стала домом для большого количества дублированного кода с небольшими отличиями. Это не только уменьшило скорость разработки и увеличило долги по технологиям, но и привело к несоответствию идентичности нашего продукта.

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

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

Технология проектирования

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

Около года назад команда разработчиков технологий в Airbnb выпустила проект с открытым исходным кодом под названием Reaction-sketchapp, который позволил компонентам React визуализироваться в Sketch. Сообщество React отреагировало положительно, и довольно скоро стилизованные компоненты выпустили расширение своей библиотеки styled-components / primitives с поддержкой многоцелевого рендеринга (включая рендеринг в Sketch). Эти проекты стали основными техническими решениями проблем несоответствия, с которыми мы столкнулись.

Библиотека компонентов AirSwap

После исчерпывающего аудита виджета AirSwap мы идентифицировали и воссоздали в Sketch набор компонентов, которые должны были использоваться во всех настоящих и будущих функциях. Затем мы нашли время, чтобы воссоздать всю эту библиотеку компонентов в React, используя в качестве основы styled-components / primitives. Наши компоненты были отображены в виде символов через Reaction-sketchapp, создавая единый источник правды для наших проектов.

Реагировать на компоненты, представленные в Sketch

Создание библиотеки компонентов стало основой нашего предварительного сквозного процесса проектирования в AirSwap. Проекты для компонентов были на первом месте, а затем были внедрены. Поскольку мы использовали styled-components и Reaction-sketchapp, мы могли отрисовать реализованный код обратно в Sketch для проверки. После утверждения предоставленные компоненты станут новыми проектами, готовыми к будущему пересмотру в случае необходимости.

Несколько версий библиотеки компонентов, отображаемых в Sketch и загружаемых в Figma

Введите фигма

Этот цикл устраняет несоответствие между кодом и дизайном. Тем не менее, мы быстро обнаружили дополнительные преимущества этого решения, когда начали выполнять большую часть наших дизайнерских работ на Figma. Поскольку наши инструменты проектирования позволяют нам создавать документы Sketch из нашей библиотеки компонентов, мы загружаем каждую новую ревизию в Figma. Комментарии и запросы на изменения могут быть сделаны в интерактивном режиме на последней редакции, которая предоставляет спецификации для следующей редакции, только для загрузки, когда будут учтены все предыдущие комментарии. Это не совсем гладко (пока), но оно создает процесс просмотра пользовательского интерфейса, который информативно похож на запросы GitHub.

Использование нашей новой библиотеки компонентов для создания макетов для новой внебиржевой торговли AirSwap.

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

Название компонента отображается в Figma, который сразу же предоставляет информацию разработчикам, просматривающим макеты

Что дальше

Двигаясь вперед, мы намерены улучшить и настроить этот процесс, чтобы более органично вписаться в нашу работу по разработке продукта. Есть еще несколько ручных и неэффективных шагов.

Например, в настоящее время Figma не предоставляет API-интерфейс с поддержкой записи для документов, что требует от нас загрузки вручную созданных файлов Sketch. При надлежащей поддержке API мы можем легко интегрировать этот сквозной процесс в наш конвейер непрерывной интеграции. Мы предвидим будущее, когда конвейер CI рендерит файл Sketch из тега или ветви в репозитории (или, что еще лучше, рендерит собственные объекты Figma вместо прохождения через Sketch), загрузит этот файл в Figma и свяжет полученный документ с извлечением. запрос. Комментарии от Figma можно опубликовать на GitHub, обеспечивая бесперебойную связь и обратную связь между дизайном и кодом.

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

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

  • Подпишитесь на блог AirSwap
  • Присоединяйтесь к нашему официальному каналу на Telegram
  • Следуйте за нами на Twitter
  • Найти нас на Facebook
  • Подпишитесь на наш subreddit