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

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

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

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

В общем, делитесь опытом.
  • Вопрос задан
  • 299 просмотров
Пригласить эксперта
Ответы на вопрос 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 не увидел тут конкретной проблемы, сам с таким не сталкивался)
Ответ написан
Ваш ответ на вопрос

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

Войти через TM ID
Похожие вопросы
Ultimate Guitar Санкт-Петербург
от 1 000 до 5 000 usd.
Fundraise Up Санкт-Петербург
от 140 000 до 180 000 руб.
от 100 000 руб.
18 янв. 2019, в 21:37
1500 руб./за проект
18 янв. 2019, в 19:30
150000 руб./за проект
18 янв. 2019, в 18:43
1000 руб./в час