- PVSM.RU - https://www.pvsm.ru -
В предыдущей публикации [1] я рассказал о том, как мы пришли к пониманию необходимости создания дизайн-системы, и какой пруф мы можем получить от ее внедрения. И, конечно, процессы создания и внедрения не такие простые, как кажутся на первый взгляд. Мы столкнулись с рядом серьезных проблем, которые нам предстояло решить. Именно о процессе создания и трудностях пойдет речь в этой статье.
Те, кто крутятся в дизайнерской или около-дизайнерской тусовке, уже знакомы с понятием UI Kit (далее “кит”). Для тех, кто не в курсе — это набор элементов интерфейса в одной стилистике, предназначенный для сборки страниц. Обычно это Sketch или Photoshop-файлы, в которых по полочкам разложены компоненты, расставив которые, вы получите готовый макет. Но нам интересен именно тот кит, который используют не только дизайнеры, но и разработчики, менеджеры и технологи. Именно его можно назвать полноценным рабочим инструментом для продуктовой компании.
В нашем случае получилось несколько китов: один базовый и несколько продуктовых. В базовый кит мы заносим либо общие компоненты для всех продуктов, либо те компоненты, которые используются минимум в двух продуктах. В продуктовый кит попадают компоненты, которые являются уникальными для конкретного продукта.
Ниже перечислю проблемы, которые нам предстояло решить в рамках сборки первой версии базового кита:
Встал вопрос о том, какие именно компоненты нужно выносить в базовый кит. Кнопки, навигация, базовые контролы не вызывают сомнений. А что еще?
Мы пошли по пути добавления тех компонентов, которые чаще всего используются на платформе Tinkoff.ru. Команда разработки помогла нам сделать выгрузку списка всех компонентов со статистикой по количеству их упоминаний.
Этого оказалось недостаточно, так как частое упоминание компонента не значит, что он используется в самых популярных сценариях для клиента. Нужно было зайти с другой стороны, и мы пошли по менее автоматизированному пути: взяли наши самые посещаемые страницы в продуктах и руками выписывали самые важные компоненты, которые можно было переиспользовать. Это касалось как внешних страниц Tinkoff.ru, так и внутренних страниц интернет-банка.
Начинайте с компонентов, которые участвуют в типичных паттернах использования вашего продукта.
Результат не заставил себя ждать очень долго:
На Tinkoff.ru отсутствует отдельно стоящая зона личного кабинета — можно авторизоваться и продолжать серфить по продуктовым страницам сайта. Разделы авторизованной зоны появляются в главном меню, а в борде клиенту доступны его карты, счета и другие продукты.
Существующий на тот момент лэйаут был сложным технически и тяжеловесным. У него были процентные уши, и при входе в личный кабинет контент сужался динамически, чтобы освободить место для выезжающего темного борда справа (да, тогда еще борд был темный и справа). В итоге мы получали затормаживания при входе в личный кабинет, так как рендер всех этих динамических изменений контентной области ложился на фронт. Плюс на некоторых страницах ловились баги, что где-то что-то не влезло. Но таких ситуаций было немного.
Что было сделано:
Проделанная работа дала нам прирост в производительности, так как теперь контент не сужается динамически, а просто смещается вправо, при этом не важно, какое состояние борда активно, свернутое или развернутое. Новое поведение, фиксация и небольшое увеличение контентной области упростило нам тестирование страниц и избавило нас от незначительных багов с тем, что где-то что-то не влезло.
Уже на ранней стадии создания базового кита мы понимали, что хотим взять опыт разработчиков по работе с кодом и внедрить его на нашей дизайнерской кухне. То, что есть у нас в ките, должно быть у них. Не должно быть никаких расхождений. Нам нужно было создать единое пространство для того, чтобы поддерживать актуальность кита.
У разработчиков давным давно с этим все хорошо. Ни один крупный проект не обходится без системы контроля версий (Git, Github, SVN, Mercurial). Что касается дизайна, то здесь инструменты только начинают появляться, и одним из них является Abstract [2]. Его преимущества:
Мы активно используем Abstract для версионирования базового кита. С его помощью можно контролировать и сохранять историю любых изменений, а также иметь доступ к любой версии любого компонента в момент необходимости. Abstract записывает абсолютно все.
Любая версия. Любой компонент. В любое время.
С точки зрения дизайна и разработки, мы используем один подход — семантическое версионирование (semver) компонентов. Это означает, что версия представляется в виде трех целых цифр, разделенных точкой (например 2.4.1). Первая цифра называется мажором версии, вторая минором, а третья — патчем.
Изменение версии для дизайна:
Изменение версии для разработчиков:
Каждый компонент версионируется по этому подходу.
Одна из важных задач — сформировать полное соответствие компонентов дизайн-команды с компонентами, которыми пользуются разработчики. Учитывая тот факт, что у дизайнеров и разработчиков происходит версионирование каждого компонента, нам нужно было понять, на каком из трех уровней возможна синхронизация.
Сравнивать компоненты по патч-версии не было смысла, так как баги, которые могут появляться в дизайне и разработке, существенно отличаются. Но если в макете компонента появляется новое состояние, то логично, что оно должно появиться и в его живом аналоге. Обговорив этот момент с разработчиками, мы взяли за правило, что компоненты синхронизируются, начиная с минор-версии, а патч-версии могут быть разными.
Результат таких нехитрых манипуляций:
Мы применяем React Storybook для отображения и использования наших компонентов, но в его исходном виде: он неудобен для всех, кроме разработчиков. А нам хотелось собрать всю информацию по дизайн-системе в одном месте и сделать ее доступной для всех:
Этот инструмент будет полезен абсолютно всем членам команды: дизайнерам, разработчикам, менеджерам и технологам.
Это отличный способ ознакомится с принципами и всеми компонентами дизайн-системы, понять, как как это все работает и собирается в единое целое.
Он даст понимание, насколько объемен тот или иной продукт, из каких компонентов состоит.
Позволит более точно дать оценку при внесении изменений или разработке фич.
Ответит на вопросы, как устроен компонент, откуда берутся данные и что с ними происходит.
Мы начали разработку собственной витрины для нашей дизайн-системы и наделили ее следующей функциональностью:
Создание и внедрение дизайн-системы – сложный, но необходимый процесс для крупных компаний с большим количеством разных продуктов. И мы постараемся рассказать о всех подводных камнях, с которыми нам пришлось столкнуться. Следующие статьи будут посвящены регламентам, бизнес- и дизайн-процессам.
Автор: iamnickparker
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/interfejsy/265197
Ссылки в тексте:
[1] предыдущей публикации: https://habrahabr.ru/company/tinkoff/blog/326782/
[2] Abstract: https://www.goabstract.com/
[3] Источник: https://habrahabr.ru/post/339660/
Нажмите здесь для печати.