Когда я попал в инфраструктурный отдел Wildberries, там было более 10 продуктов, каждый из которых разрабатывался отдельной командой. Все использовали MUI, но зачастую кастомизировали компоненты по-своему.
Я увидел следующие проблемы:
Разрозненный пользовательский опыт. В разных продуктах компоненты и паттерны взаимодействия работали по-разному.
Дублирование усилий. Иногда команды разных проектов создавали одинаковый функционал независимо друг от друга.
Проблемы с доступностью. Навигация с клавиатуры часто отсутствовала или работала некорректно. Иногда встречались элементы с недостаточной контрастностью.
Хаос в системных сообщениях. Единые правила написания сообщений отсутствовали. Это приводило к тому, что даже в одном продукте заголовки модальных окон или системный фидбек при похожих действиях выглядели по-разному.
Решением этих проблем могла стать единая дизайн-система. Так как у меня уже был опыт в создании таких систем, я предложил свою помощь.
Со вторым дизайнером, который сразу поддержал мое предложение, мы составили презентацию для руководства. В ней обозначили текущие проблемы, объяснили, как дизайн-система сможет их решить и другие преимущества использования дизайн-системы.
Презентацию провели для ключевых менеджеров и тимлидов отдела. Они встретили инициативу с пониманием, и на той же встрече мы получили одобрение.
Я изучил текущий дизайн продуктов, чтобы понять, какие компоненты используются и какие задачи они решают. Нашёл дизайн-системы, созданные для похожих продуктов, чтобы использовать в качестве референсов.
Также мы определили принципы будущей дизайн-системы и ознакомили с ними других дизайнеров.
Масштабируемость. Когда появляется потребность создать новые компоненты, дизайн-система остаётся последовательной. В нашем случае набор семантических токенов позволял легко создавать новые компоненты, при этом они органично сочетались с существующими.
Доступность. Сочетания цветов соответствуют стандартам WCAG. Все компоненты поддерживают навигацию с клавиатуры и работу со скрин-ридерами. Характер компонентов передаётся не только цветом, но и иконками, текстом. К компонентам прилагаются рекомендации по обеспечению доступности, где это необходимо.
Независимость. Компоненты не имеют жёстких зависимостей друг от друга, каждый существует сам по себе и может комбинироваться с другими.
Переиспользуемость. Компоненты спроектированы так, что их можно настраивать для решения различных задач без изменения кода.
Адаптивность. Поведение и визуальное отображение компонентов в разных темах интерфейса (светлая/тёмная), при разных размерах экрана, в различных состояниях предусмотрено на уровне дизайн-системы.
Документация. Каждый компонент сопровождается правилами и примерами его использования, анатомией и другими разделами документации по необходимости.
Далее я завёл систему дизайн-токенов и типографики, написал базовую документацию.
Я начал с самых простых — кнопки, меню, различные типы инпутов. Постепенно переходил к более сложным. Сложные компоненты часто содержали в себе простые, поэтому базовые нужно было сделать в первую очередь.
Для каждого компонента я сразу писал документацию в Figma. Позже, когда у нас появился Storybook, мы её доработали и перенесли туда.
При создании компонентов я использовал:
Пропы — настройки для управления внешним видом и функционалом компонента.
Слоты — места в компоненте, куда можно вставлять другие компоненты в зависимости от сценария использования.
Дефолтный контент — стандартное наполнение, которое можно было вставить на место слота, покрывавшее основные сценарии использования.
Примерно через полтора месяца к проекту подключился ответственный за дизайн-систему фронтенд-разработчик. К работе над компонентами также привлекались разработчики из других проектов, когда там появлялись свободные ресурсы.
Мы завели доску в таск-трекере с разделами для дизайна и разработки. Каждая карточка отвечала за один компонент, и сначала проходила через колонки раздела дизайна, затем перемещалась в разработку.
На ревью обсуждали, как компонент должен работать, какие у него есть пропы и за что они отвечают. Периодически возникали споры о семантике названий. Например, компонент Toast — всплывающее уведомление о событии. Некоторые разработчики хотели назвать его Alert, но Alert подразумевает тревогу или ошибку, а Toast предназначен для любого характера обратной связи. Где-то я был не прав, где-то доносил свои мысли. В ходе обсуждений происходил ценный обмен опытом.
Обучение дизайнеров работе с дизайн-системой началось параллельно с её созданием. С появлением новых компонентов я просил изучать документацию к ним. Проводили воркшопы, на которых со вторым дизайнером показывали, как использовать компоненты на примерах реальных задач. Дизайнеры задавали вопросы и давали обратную связь, которую я использовал для доработки компонентов.
Когда в коде была готова большая часть компонентов, система начала активно применяться в проектах.
С активным использованием дизайн-системы в некоторых компонентах становились понятны их недостатки, как в удобстве использования, так и в логике работы. Я оперативно их исправлял. Правки были разные, иногда мелкие, а иногда приходилось делать рефакторинг всего компонента.
Был разработан процесс управления дизайн-системой, который описывал, как дизайнеры могут предлагать изменения существующих компонентов или запрашивать новые.
Также я выработал принципы создания макетов и чеклист для проверки их качества.
Основная работа по созданию дизайн-системы заняла 8 месяцев. За это время было создано около 80 компонентов.
На дизайн-системе были созданы 4 новых продукта, еще 3 частично на неё перешли.
Для команд разработки процесс стал проще. Разработчикам больше не нужно кастомизировать компоненты MUI и спрашивать у коллег из соседних проектов, делал ли кто-то подобное. Storybook стал единственным источником правды, доступным всем, с документацией и возможностью протестировать, как работают компоненты.
Дизайн-токены позволили создавать интерфейсы в светлой и темной темах без дополнительных усилий со стороны дизайнеров и разработчиков.
На первые ревью компонентов мы приглашали много разработчиков — около 10 человек. Беседа превращалась в хаотичное, непродуктивное обсуждение из-за большого количества мнений. После пары таких встреч мы ограничили состав участников, сначала до ответственного за дизайн-систему фронтенд-разработчика и тимлида фронтеда, а затем и только до ответственного разработчика.
Изначально все компоненты создавались и хранились в одном Figma-файле. Когда компонентов стало много, в том числе сложных, начались проблемы с производительностью поиска по библиотеке. Решением стало разнесение компонентов по отдельным файлам.
Некоторые компоненты на практике оказались слишком сложными в настройке. Для таких я проводил рефакторинг, искал способы упростить их, сохранив гибкость.
