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

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

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

Пример 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.

В общем, делитесь опытом.
  • Вопрос задан
  • 1846 просмотров
Пригласить эксперта
Ответы на вопрос 2
Nekto_Habr
@Nekto_Habr
Жёстко и правдиво: https://vms-blog.ru
Мда, чуваки придумали охрененно крутую новую парадигму работы над дизайном, но по сути кинули щенят в реку, а нам теперь самим выплывать. Сам миллиард раз переделывал один и тот же макет, т.к. в процессе постоянно приходили новые идеи, как этот самый процесс оптимизировать.

По поводу цветов. Есть два подхода, старый и новый.

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

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

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

5c26392b5b998478772190.png

По поводу твоей проблемы - а ты не пробовал инструменты выделения?
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. Суть в том, что при экспорте компонентов в файлы на жесткий диск образуются ломанные папки, если юзать пробелы вокруг слэшей.
Ответ написан
mixail_fet
@mixail_fet Куратор тега Дизайн
Дизайнер веб-интерфейсов
Пример 1 - 2: чтобы не создавать несколько разных документов, а потом не переключаться на них от тех, которые принял клиент и тех, которые не принял, существует "история версий".

Например: сегодня мне написал заказчик, что цвета на всех моих кнопках - ужасные.
Теперь мне надо изменить все цвета, и я захожу в
историю действий
5c2625e89d6e3692164839.png
и задаю
имя текущей правки
5c2625dc4f054979224799.png
И она у меня сохраняется. Я потом могу вернуться к ней, вытащить из нее отдельные элементы или восстановить полностью, но она храниться всего 30 дней (если используешь бесплатную версию Figma).

Пример 3 самый удобный способ хранить компоненты для всего проекта - это командная библиотека (и да, она стоит того, чтобы отдавать 1000 рублей/месяц), потому что в следствие, для большого проекта, можно идеально продумать все стили, особенно если в рамках одного проекта, делаешь несколько сайтов. Библиотека компонентов всегда в быстром доступе, там есть поиск по ключевым словам. При желании, можно создать свою библиотеку иконок и вытаскивать ее для всех проектов. Если дорого - я всегда прятал компоненты на отдельную страницу, дискомфорта не вызывало.

Пример 4 не увидел тут конкретной проблемы, сам с таким не сталкивался)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
от 135 000 до 150 000 руб.
Ситимобил Москва
от 150 000 до 250 000 руб.
от 120 000 до 180 000 руб.