[Анализ и проектирование систем, Интерфейсы, Дизайн] Архитектура дизайн-системы для нескольких продуктов

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 4 месяца
Сообщений: 27286

news_bot ^® написал(а)
10-Янв-2021 01:30

Цитировать

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

Есть несколько продуктов.
Один продукт могут делать несколько команд дизайнеров и разработчиков.
Есть Web, Mobile и Desktop.
Есть много легаси и неконсистентности.
Дизайнер в одном продукте может не знать что происходит в другом.

Если будут встречаться технические нюансы, то, прежде всего, подразумевается работа в Figma, но, думаю, что в Sketcha Fernanda все то же самое.Проблемы существующих подходов к библиотекостроениюС точки зрения дизайнера, хорошая ДС начинается с библиотеки с которой удобно работать.Опыт разных команд обычно описывается одной из этих схем или их причудливой комбинацией:

Сами же проблемы можно описать следующим образом:

К одному файлу подключено несколько библиотек. Внутри файла каша из компонентов и стилей с различными родителями. Дизайнеры боятся трогать библиотечные компоненты, потому что непонятно где они используется и что может сломаться.
Библиотека слишком большая. Работая над фичей, дизайнер абстрагируется от перегруженной и сложной библиотеки. Он собирает и детачит компоненты прямо в рабочем файле, надеясь, что однажды они просто перетекут в библиотеку и станут "легальными". Чтож, удачи.
Собираются кондовые интерфейсы, ведь все зарегулировано и засинхронено с кодом. Из развлечений остается только перебирать комбинаций расположения двух полей и кнопки, которое тоже зарегулировано.
Это невозможно масштабировать.

Из нытья выше можно выделить основные источники боли: неуправляемость, избыточность и сильная связанность. Проще говоря, проблема в мега-библиотеке, к которой все привыкли, на которой все завязано и которая все ломает. С ней и решили бороться.Принципы и приоритетыНачать проектирование ДС стоит с формулирования принципов, которые бы исключили приход к чему-то неподходящему. Мне не хотелось изобретать полностью свой велосипед, поэтому многие его детали были позаимствованы у разработки: для дизайн-системы YAGNI и первые две буквы SOLID, а для компонентной базы DRY и KISS.Принципы — это хорошо, но слишком идеализированно. Нужны и приоритеты.

Если нам нужна лучшая конфета, то что важнее, ее шоколадность или вкусность? — Конечно же шоколадность, это легко.

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

Управляемость > Консистентность > Кастомность
Легкость поддержания > Легкость создания
Однозначность > Объем компонентной базы

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

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

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

Новые правила игрыКоманда нового продукта начинает игру с базовой библиотекой, наполненной только самыми базовыми компонентами и стилями из референсной. В ней вообще не должно быть ничего, что сейчас не используется в продукте. Никаких стилей и компонентов "про запас". Когда команде нужно что-то добавить, она заглядывает в референс. Если в референсе есть подходящий элемент, то тянет его к себе, если нет, делает свой в продуктовой либе. На ретроспективках дизайнеры обмениваются опытом компонентостроения и, если несколько команд в разных продуктах решают использовать один и тот же компонент, то он добавляется в референсную библиотеку, формируя своеобразный зал славы удачных решений.Решение изменить Референс принимается рыцарями круглого стола. Решение забить на Референс и делать по-своему принимается советом рыцарей отдельного продукта, но им нужны благословления других важных персонажей.Теперь "мега-библиотека" не прогибает всех под себя жесткими связями между файлами, а, скорее, задает тон комнате и указывает правильное направление развития для продуктовых библиотек. Команды сами решают, когда они раскатают изменения внесенные в Референс по своим библиотекам и когда релизнут это в продуктах.Дизайн-системаРазобравшись с библиотекой можно усложнить задачу, достроив ее до дизайн-системы. В целом, сохраняется тот же подход, но элементов становится чуть больше.Для каждого компонента на базовом уровне должно быть уже три представления:

Компонент в фигме — то как он выглядит.
Спецификация — гайд который рассказывает как компонент работает, где его можно использовать, а где нет и почему.
Код.

Все вместе это уже можно считать дизайн-системой на минималках.МодулиЧтобы было понятно с чем мы интегрируем нашу ДС, стоит немного рассказать о продуктах, которые она обслуживает. Модульный подход в дизайне это тема отдельной заметки и я о нем еще обязательно расскажу, но пока нам достаточно следующей аппроксимации. Пускай наш продукт это онлайн магазин. Для простоты будем считать что у него есть только Личный кабинет, Корзина, Витрина и Авторизация. Каждый такой кусок мы выделяем в отдельный модуль и создаем под него отдельный файл в фигме. Все экраны, касающиеся одного модуля, лежат только в файле модуля и нигде больше.Тогда весь продукт представляет из себя кластер, состоящий из своих модулей и модуля дизайн-системы — Базиса, который их обслуживает, поставляя стили, компоненты и другие составляющие ДС.

Если посмотреть на всю структуру целиком, то получится такая штука:

Базисов столько же, сколько и продуктов, но все они стараются быть похожими на референс.С помощью такого хака мы поддерживаем асинхронные обновления продуктов и высокий уровень консистентности, при этом уходим от прямой связанности и лишних компонентов в продуктовых библиотеках. Что дальше?На самом деле, тема библиотеки не раскрыта, и там все еще можно наломать очень много дров. В нейминге, компонентах, стилях, да даже в самом процессе работы с ней есть нюансы. Поэтому в следующих заметках я расскажу как мы собираем компоненты, экраны и что там у нас с версионированием. Ну и какая же дизайн-система без описания подхода к упорядочиванию цветов, типографики и стилей, об этом тоже расскажу.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_interfejsy (Интерфейсы), #_dizajn (Дизайн), #_dizajn (дизайн), #_dizajnsistemy (дизайн-системы), #_interfejsy (интерфейсы), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_interfejsy (
Интерфейсы
), #_dizajn (
Дизайн
)

Профиль ЛС

Ответить на тему

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

Текущее время: 16-Июн 11:18
Часовой пояс: UTC + 5