Дизайн система - как мы внедрили у себя стандарт для создания приложений

Дизайн-система - это библиотека переиспользуемых фрагментов интерфейса, текста и визуала (цветовых палитр, иконок, кнопок и других элементов), из которых можно собрать типовые пользовательские сценарии. По сути это набор стандартов, подходов и инструментов для управления дизайном продукта.

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

Из опыта других компаний мы уже знали об особенно важных для нас преимуществах:

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

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

Проанализировав множество доступных вариантов, мы решили отстраивать свою систему на базе опенсорсной библиотеки Material UI. Это библиотека готовых к использованию компонент на React, которая реализует Material Design от Google, при этом многие компоненты доступны к использованию “прямо из коробки”.

Для нас также крайне важно было, что у Material UI есть вся актуальная документация на английском языке, а у нас есть наработанная экспертиза и положительный опыт ее использования. У библиотеки обширное комьюнити разработчиков, она часто обновляется, гибко настраивается и в целом понятна с первого взгляда.

Мы решили использовать подход Atomic Design, в соответствии с которым дизайн-система состоит из так называемых атомов, молекул, организмов, шаблонов и страниц.

Атомы - простейшие “строительные” элементы интерфейса, которые нельзя разобрать на простейшие, не потеряв их функциональности, например кнопки, текст, обводка, иконка. Атомы могут быть и абстрактными. Например, шрифт, динамический эффект, цветовая палитра. Молекула - это более сложные компоненты, например поля ввода (поле может содержать и иконку, и текст, и рамку и т.п.). Организм - форма ввода и т.п

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

Требования к новым компонентам формировались “на лету”. Мы понимали, какие компоненты необходимо реализовать в первую очередь и приступали к реализации..

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

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

Разработка компонент шла параллельно в Storybook. Это еще один инструмент JavaScript для работы с пользовательскими интерфейсами, который позволяет немного повысить эффективность работы - разработку, тестирование и документирование.

Мы воспользовались их подходом Component-Driven Development (CDD), в рамках которого компонент - это основной строительный блок интерфейса.

По нашей схеме работы разработчик, у которого возникала необходимость доработать или создать новый компонент в дизайн-системе, не передавал эту задачу другому, а заканчивал сам, даже если это был какой-нибудь сложный автокомплит с кучей вариантов использования, в зависимости от разрешения экрана. Такой подход выбрали из-за особенностей нашей команды - у нас нет выделенных фронтов и бэкендеров; большая часть команды - это full stack.

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

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

И уже на финальном этапе новый код тестировался. У нас вся функциональность приложения и интерфейс покрыты различными тестами. В частности, мы используем снапшот тестирование: сравнение текущего скриншота экрана с эталонным.

Снапшоты дают больший контроль над конечной HTML разметкой, которая попадает в продакшен. Это особенно актуально, когда работаешь с Material UI - она по умолчанию добавляет элементы, которые не всегда можно увидеть, например эффекты вроде Touch Ripple (визуальный эффект, который используется для отображения зарегистрированных касаний). При появлении таких нюансов их можно убрать с помощью указания нужных props (входных данных React-компонентов, передаваемых от родительского компонента дочернему).

Снэпшот-тесты полезны, но у них есть тёмная сторона: любое изменение в UI–ките порождает сотни апдейтов в файлах снэпшотов. В нашем случае ситуацию усугубляет MUI – фрейморк генерит огромное количество анти-семантических тегов-обёрток, которые делают HTML-верстку тяжело читаемой.

В итоге перед разработчиком появляется соблазн прокликать на автомате все 200 повторяющихся изменений. Это и есть главная причина почему команды отказываются в конечном итоге от снэпшотов.

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

Дизайн-система активно используется нами в нескольких проектах. И мы постоянно ее дорабатываем.

Пример применения дизайн системы можно найти в нашем приложении PWA.

Ранее писали об этом статью.