Как вы систематизируете компоненты и стили в Фигме?
=====================================================

 Мой опыт работы с Фигмой - около года. Не так уж мало, но до сих пор я не могу прийти к оптимальной организации макетов.  
  

Как известно, идеология Фигмы базируется на компонентах и стилях. И всё в них вроде бы это хорошо и логично... Но только при условии, что дизайн развивается строго поступательно и гладко. В реальной жизни так почти не бывает - постоянно приходится пробовать альтернативные решения и экспериментировать.  
  
**Пример 1**  

У меня есть 10 цветов, записанных в именованные стили. Казалось бы, всё удобно: меняешь одну переменную - меняется везде.  

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

Сложнее другое - как мне найти все элементы, имевшие заливку brand-color-old и заменить её на brand-color-new? Парадокс: стили придуманы для того, чтобы не лазить по сотням элементов и не менять вручную цвета - но всё равно приходится лазитьь и менять, только не цвета, а стили.  
  
**Пример 2**  

Есть кнопки, каждая разновидность (primary/secondary/etc) и состояние (hover/etc) в своем компоненте. Приходит заказчик - а вот давайте попробуем вместо квадратных кнопок скругленные!  

Я должен клонировать все кнопки, детачить их от оригинала, создать отдельные компоненты - это понятно. Но потом я должен обползать макет и в сотне мест заменить инстансы.  

Да, я мог бы модифицировать исходные компоненты, но я хочу сохранить предыдущую версию! Но не просто "бэкап на всякий случай" (тогда можно было бы просто сохранить на диск файлик some-mockup.fig.bak), а так, что бы можно было продолжать параллельно работать с обеими версиями и в процессе решить, какая лучше.  
  
**Пример 3**  

Где лучше хранить компоненты в многостраничном документе?  

Выделять отдельную страницу? Логично, но на практике задалбыват постоянно прыгать со страницы на страницу.  

Размазанно по страницам? Удобнее поначалу, но потом боль от хаоса.  
  
**Пример 4**  

Думаю, всем известно, что компоненты можно раскладывать по папкам при помощи слэша.  

Типа: button / primary / hover. Помимо упорядочивания, это даёт удобную смену инстанса на "родственный" - например, быстро поменять простую кнопку на нажатую, и не искать её среди сотен других компонентов.  

Проблемки тут две.   

Во-первых, эти цепочки сильно растут, примерно так: desktop / dark theme / button / primary / hover.  

Во-вторых, в начало цепочки пристраивается еще имя страницы - и смотри пункт 3.  
  

В общем, делитесь опытом. 

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

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

Новый - хранить цвет в стиле, тут лишний раз объяснять не нужно, но есть нюансы. Главная боль - политика именования. Как называть цвета? "Главный акцент - светлый / средний / тёмный", "Вторичный акцент - ... "? Или же "Голубой - светлый / средний / темный", "Зелёный - ..."? Или "Активный / Отключенный / Ховер"? Лично я для себя решил, что первый вариант лучше. Еще одна проблема - я хочу иметь под рукой не только лишь ограниченный набор цветовых стилей, а целую палитру, особенно актуально это в начале дизайна, когда хз какие цвета закрепятся в макете.   
  

Но это целый вагон стилей. Например в материальной палитре их 256 (гики, лол), и листать мелкую панельку со стилями банально отнимает драгоценное время. Вот в таком случае выручают компонентные цвета, т.к. компоненты аккуратно сортируются в выпадающем меню инстансов (если их правильно обозвать, разумеется).  
  
![5c26392b5b998478772190.png](https://habrastorage.org/webt/5c/26/39/5c26392b5b998478772190.png)  
  

По поводу твоей проблемы - а ты не пробовал инструменты выделения?  
![5c2639f3b2e78215242530.png](https://habrastorage.org/webt/5c/26/39/5c2639f3b2e78215242530.png)  
  

*  
**По поводу состояния элементов.** Раньше я тоже внутри кнопки хранил еще и другие ее состояния, в скрытом виде.   
  

Теперь поступаю проще - создаю отдельные компоненты её фона: активная, ховер, и т.п., и создаю компонент кнопки например из текста и компонента активного фона, который потом заменяю на disabled, focus, hover, что угодно, ну и цвет текста меняю (стилем цвета или компонентным цветом опять таки). Это сильно упрощает структуру кнопки и улучшает вид стопки слоёв.  
  

По поводу твоей проблемы - ты создаешь отдельные компоненты, и потом облазишь макет и заменяешь инстансы на новые дизайны, а ты попробуй сделать ровно наоборот: создай копии оригинальных компонентов, детачни их в качестве бек-апа, и смело модифицируй оригиналы. В теории, это сэкономит время, т.к. дизайн поменяется автоматически, а если что - переделаешь потом компоненты на старый лад. Этот процесс сильно ускоряется шорткатами ctrl+alt+c и ctrl+alt+v (копирование и вставка свойств объекта) с зажатым ctrl (это позволяет проникать внутрь группы в один клик).  
  
**По поводу хранения компонентов.** Я вообще изначально приучил себя складывать компоненты на отдельный фрейм, а не оставлять их там, где они были созданы. Геморрно конечно, но в итоге такой подход гораздо продуктивнее.  
  

А проблема с прыжками ко фрейму (или выделенной странице) с компонентами и обратно к макету решается очень просто: я тупо перетаскиваю все компоненты поближе к макету, с которым я в данный момент работаю, даже если он на другой странице. Сильно экономит время.   
  
**По поводу политики имён компонентов.** Здесь хорошо действует принцип, позволяющий грамотно организовывать папки на жестком диске: структура каталогов должна быть максимально плоской. Даже для крупного проекта достаточно создать всего три фрейма:  
  

- Иконки (даже если под сотню)  

- Элементы интерфейса (атомы и молекулы)  

- Интерфейсы (организмы и страницы)  
  

Ну и если решил создать компонентные цвета - еще и для них фрейм. **Внутри этих фреймов не нужно использовать слеши в названиях компонентов!** Компоненты будут наследовать имена страницы и фрейма, на котором они находятся, типа Page1/icons/vk-logo. Понятно, что например иконок может быть под сотню, но в итоге такая плоская структура сильно способствует скорости работы, а быстрый поиск в длиннющем списке через меню инстансов должен облегчаться грамотными префиксами и суффиксами названий, например вместо того чтобы создавать отдельный каталог иконок соцсетей вида Page1/icons/social/vk, нужно тупо название этого каталога сделать префиксом: Page1/icons/social-vk  
  

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

Важный момент в каталогизации компонентов: не оборачивайте слэши пробелами! То есть, именовать нужно вот так: catalogue1/subcatalogueA/component-alpha, а не catalogue1 / subcatalogueA / component-alpha. Суть в том, что при экспорте компонентов в файлы на жесткий диск образуются ломанные папки, если юзать пробелы вокруг слэшей. 

**Пример 1 - 2:**  чтобы не создавать несколько разных документов, а потом не переключаться на них от тех, которые принял клиент и тех, которые не принял, существует "история версий".   
  
**Например:** сегодня мне написал заказчик, что цвета на всех моих кнопках - ужасные.   

Теперь мне надо изменить все цвета, и я захожу в **историю действий**![5c2625e89d6e3692164839.png](https://habrastorage.org/webt/5c/26/25/5c2625e89d6e3692164839.png) и задаю **имя текущей правки**![5c2625dc4f054979224799.png](https://habrastorage.org/webt/5c/26/25/5c2625dc4f054979224799.png) И она у меня сохраняется. Я потом могу вернуться к ней, вытащить из нее отдельные элементы или восстановить полностью, но она храниться всего 30 дней (если используешь бесплатную версию Figma).  
  
**Пример 3** самый удобный способ хранить компоненты для всего проекта - это командная библиотека (и да, она стоит того, чтобы отдавать 1000 рублей/месяц), потому что в следствие, для большого проекта, можно идеально продумать все стили, особенно если в рамках одного проекта, делаешь несколько сайтов. Библиотека компонентов всегда в быстром доступе, там есть поиск по ключевым словам. При желании, можно создать свою библиотеку иконок и вытаскивать ее для всех проектов. Если дорого - я всегда прятал компоненты на отдельную страницу, дискомфорта не вызывало.  
  
**Пример 4** не увидел тут конкретной проблемы, сам с таким не сталкивался)