С какими сложностями мы столкнулись, внедряя стандарт внутри компании.
Переходя на новый стек, мы параллельно задумались об эффективности работы команд. И одним из важных шагов в этом направлении стало внедрение общей дизайн-системы для всех проектов компании.
О дизайн-системах на Хабре писали много. Это библиотека переиспользуемых фрагментов интерфейса, текста и визуала (цветовых палитр, иконок, кнопок и других элементов), из которых можно собрать типовые пользовательские сценарии. Удобны они не столько заказчикам продуктов, сколько самим разработчикам.
Открытые дизайн-системы нам не подошли - их возможностей оказалось недостаточно для реализуемых проектов, поэтому мы пошли по пути кастомизации. Об этом и хотим рассказать. С доработкой, как всегда, были некоторые нюансы и ограничения. Но - спойлер - мы с ними справились, успешно закончив этап MVP.
Итак, нам нужна была дизайн-система. Почему и зачем - подробно писали на VC, здесь повторяться не будем.
Разрабатывать с нуля мы не видели смысла - на рынке достаточно много открытых дизайн-систем, которые можно взять за основу. Мы посмотрели несколько, как отечественных, так и зарубежных. После недолгих размышлений в качестве основы взяли опенсорсную библиотеку Material UI от Google. Мы пишем на React, уважаем принципы Material Design и искали что-то адаптивное, кроссбраузерное и достаточно гибкое. А у Material UI, помимо соответствия этим пунктам, есть есть актуальная документация на английском языке и обширное комьюнити разработчиков с частым выпуском обновлений. Кроме того, у на была наработанная экспертиза и положительный опыт ее использования.
Material UI гибко настраивается и в целом понятна с первого взгляда. От нас требовалось доработать существующие и создать новые компоненты так, чтобы не нарушить ее консистентность - т.е. чтобы наши компоненты соответствовали стилю и правилам дизайна библиотеки, а также были интегрированы с цветовыми схемами, типографикой и т.п. При этом надо было избежать дублирования.
Ход разработки
Своеобразным триггером для разработки дизайн-системы стал один из проектов PWA-приложения и работа шла параллельно. Roadmap приложения включал MVP, MMP и полную версию, а дизайн-систему готовили в соответствии с требованиями очередного этапа разработки приложения.
Например, на этапе MVP на главном экране приложения должна была отображаться минимальная информация - соответственно, и компоненты разрабатывались по самым простым сценариям, из идеи, что лучше сделать их максимально простыми, но с возможностью последующей доработки.
У этого подхода был недостаток - при переходе к MMP, а потом и к полной версии PWA некоторые компоненты пришлось дорабатывать. А масштабные изменения в компоненте тянули за собой ревью всех остальных сценариев, куда он входил. Некоторые компоненты даже приходилось переписывать, поскольку усложнение не пошло им на пользу - после расширения сценария первоначальное расположение свойств оказалось не оптимальным. Помножьте это на один из минусов Material UI - библиотек генерирует очень сложную вложенную структуру HTML дерева, и порой там просто не разобраться, что за что отвечает.
Однако мы оценивали разные подходы на старте и этот (даже с учетом необходимости снова и снова возвращаться к одним и тем же компонентам) представлялся наименее трудозатратным. Приложение-то надо было запустить максимально быстро, у нас и так сроки были довольно сжаты. Плюс требования к новым компонентам формировались “на лету”. При переходе от одного этапа разработки приложения к другому, они могли меняться в соответствии с требованиями бизнеса. Поэтому “продумать все заранее” внутри дизайн-системы было просто невозможно.
Итеративная разработка не ломала agile-подход, но требовала довольно много коммуникаций внутри для согласования постоянных изменений. И об этом хочется поговорить отдельно.
Команда и коммуникации
В идеале под разработку дизайн-системы нужна отдельная команда, чей фокус будет только на компонентах. Но сейчас конфигурация команд у нас такова, что людей на это не выделить. Поэтому к дизайн-системе подключались все, кто свободен или работает над упомянутым выше PWA приложением. В итоге кастомизацией Material UI параллельно занимались и дизайнеры, и фронтендеры. В общей сложности рабочая группа состояла из 5 человек.
После определения требований первыми вступали в работу дизайнеры. По началу задачей занимался всего один человек. Нам повезло, что на старте проекта ответственным за систему оказался дизайнер, который имел опыт в разработке. Это существенно ускорило процесс, помогло сразу выбирать оптимальные решения и находить общий язык с разработчиками. Впоследствии к доработке дизайн-системы подключились и другие дизайнеры.
Основным средством для подготовки визуала дизайнерами была Figma. Это распространенный командный инструмент, фактически, стандарт. В ней можно экспериментировать с визуалом, попутно формируя ТЗ для разработки за счет подробного описания свойств компонента и его поведения. Там же можно хранить библиотеку компонентов.
Разработка компонент шла параллельно в Storybook. Это еще один инструмент JavaScript для работы с пользовательскими интерфейсами, который поддерживает React и позволяет немного повысить эффективность работы - разработку, тестирование и документирование. Фактически это изолированная среда, позволяющая работать совместно и визуализировать компоненты. На старте мы использовали не все ее возможности, но планируем еще углубиться.
Кастомизируя Material UI, мы все время помнили о необходимости сохранять консистентность дизайн-системы, поэтому позаботились о том, чтобы выстроить коммуникации между ключевыми участниками команды. Параллельно у разных разработчиков и дизайнеров в работе было множество сценариев. Важно было синхронизироваться, чтобы не создавать несколько одинаковых решений. Для этого команды дизайна и разработки регулярно созванивались внутри и проводили демо. Дизайнеры проводили ревью для разработчиков, а те в свою очередь давали обратную связь дизайнерам - правильно ли они собрали компонент, корректно ли назвали свойства, оптимально ли то или иное решение.
Когда компонент считался законченным, обязательным этапом было ревью от лида, - перед добавлением кода в репозиторий тот убеждался, что нет ошибок и результат действительно соответствует задаче.
В целом работа над дизайн-системой - в первую очередь о том, чтобы ничего не сломать у других. И это немного повлияло, в том числе, на распределение задач. По нашей схеме работы разработчик, у которого возникала необходимость доработать или создать новый компонент в дизайн-системе, не передавал эту задачу другому, а заканчивал сам, даже если это был какой-нибудь сложный автокомплит с кучей вариантов использования, в зависимости от разрешения экрана. Такой подход выбрали из-за особенностей нашей команды - у нас нет выделенных фронтов и бэкендеров; большая часть команды - это full stack.
Чтобы не потерять изменения, со временем мы выделили со стороны дизайнеров так называемого “хранителя” дизайн-системы, т.е. человека, полностью ответственного за нее. Он участвует во всех этих коммуникациях. Периодически также проводит ревью всех компонентов и формирует бэклог задач.
Внедрение доступности
Помимо новых компонент, которые были необходимы для нашего PWA-приложения, мы по возможности внедряли в дизайн-систему доступность. Требований по доступности со стороны заказчика приложения не было, но мы планировали использовать UI kit и в других проектах, кроме того наши дизайнеры поддерживают этот тренд.
Со стороны дизайна продумывали, какие параметры доступности для тегов можно внедрить, и готовили сноски для разработчиков, которые помогали не забыть про эти теги и поставить их в нужные места.
Благодаря нововведениям интерфейсы, созданные на основе этой дизайн-системы, будут легче читаться скринридерами. Ими будет проще управлять с помощью нестандартных устройств ввода.
Тестирование
Одним из важных этапов работы над дизайн-системой оказалось тестирование.
Разрабатывая PWA-приложение, мы работали без тестировщиков. Как мы уже писали в статье, у нас все было покрыто автотестами, а ручное тестирование проводилось уже на приемке со стороны заказчика. Аналогично мы покрыли тестами и дизайн-систему. В частности, мы использовали снапшот тестирование: сравнение текущего скриншота экрана с эталонным.
Снапшоты дают больший контроль над конечной HTML разметкой, которая попадает в продакшен. Это особенно актуально, когда работаешь с Material UI - она по умолчанию добавляет элементы, которые не всегда можно увидеть, например эффекты вроде Touch Ripple (визуальный эффект, который используется для отображения зарегистрированных касаний). При появлении таких нюансов их можно убрать с помощью указания нужных props (входных данных React-компонентов, передаваемых от родительского компонента дочернему).
Снапшот-тесты полезны, но у них есть тёмная сторона: любое изменение в UI–ките порождает сотни апдейтов в файлах снапшотов. В нашем случае ситуацию усугублял сам Material UI – фреймворк генерирует огромное количество анти-семантических тегов-оберток, которые делают HTML-верстку тяжело читаемой. В итоге перед разработчиком появляется соблазн прокликать на автомате все 200 повторяющихся изменений. Это и есть главная причина почему команды отказываются в конечном итоге от снапшотов.
Но в нашем случае мы решили их оставить, но только в компонентах со сложной логикой отображения, там где отследить баг с версткой во множестве вариантов компонента будет проблематично.
Естественно, мы используем не только снапшоты. Вся пирамида автотестов у нас тестирует интерфейс.
Мы еще и предупреждения настроили. Например, у нас есть автоматическая проверка, что новая версия дизайн-системы ничего не сломала на проектах. При обнаружении проблем, она шлет нам уведомления в командный Mattermost.
Вместо итогов
Дизайн-система дошла до уровня MVP и мы уже применили ее в нескольких проектах. Об одном мы уже писали ранее. Естественно, будем дорабатывать - тут-то и начнется самое интересное.
Спасибо за помощь в подготовке материалов нашей команде разработчиков и дизайнеров.
Особое спасибо: Дмитрию Державину, фронтенд-разработчику Липтсофт и Анастасии Зыбинской - арт-директору Липтсофт.
