Не используй варианты для иконок

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

Автор: Саша Окунев #Figma #первые_шаги 20 августа 2022

image

Автор мема: Глеб Сабирзянов

В 2021 году Figma выпустила фичу «Варианты», и с тех пор дизайнеры стремятся применить варианты где только можно.

Уже несколько раз натыкался на такой вопрос в Фигма-чате: дизайнер объединяет весь свой пак иконок в компонент Icon. А потом страдает от того, что варианты образов неудобно переключать, нет превью иконок и вообще Фигма отстой.

Если мы объединяем в одну кучу слишком много однотипных свойств, варианты перестают выполнять свою функцию и проигрывают обычным компонентам без вариантов.

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

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

Почему возникает идея оборачивать иконки в варианты?

Те, кто делают это, попадают в когнитивную ловушку, руководствуясь логикой, что подобное стремится к подобному и каждый компонент должен быть отражён в дизайне и коде лишь один раз. С точки зрения фронтенд-библиотеки иконка — это действительно один тип компонента и поэтому кажется логичным объединить все мастера иконок в один компонент Icon, чтобы добиться соответствия этого компонента в UI-ките и фронтенд-библиотеке. Но на уровне UI-кита они точно должны быть разными просто потому, что так устроена Figma.

Любое решение в дизайн-системе должно быть продиктовано целесообразностью и здравым смыслом, а не бездумным следованием стандартам и правилам.

 ❌ Почему так делать не надо

  1. Когда будем искать компонент в поиске, будет отображаться только первый вариант, даже если ищем другие. Не используем потенциал поиска по компонентам для демонстрации превью.
  2. image
  3. Исходя из первого пункта, мы теряем возможность смотреть описания иконок по ховеру, потому что находим всегда только один результат: Icon.
  4. image

  5. Если библиотека большая, при переключении варианта будем видеть огромный список иконок вперемешку, что неудобно. Их последовательность можно задать, отсортировав слои в группирующем мастер-компоненте. Положение иконок по координатам X или Y на их последовательность в выпадашке не влияет.
  6. image

 ✅ Как делать надо

  1. Все иконки — независимые мастер-компоненты и хранятся в боксах стандартного размера. Типичный размер соответствует гайдам Material, но применим и для iOS — 24 dp/pt.
  2. image
    📌
    Если система большая, можем определить дополнительные размеры. В системе, над которой я работаю сейчас, они равны 16, 24, 40 и 72.

  3. В ките разделяем иконки на небольшие группы по размеру смыслу, чтобы было удобнее держать их в порядке.
  4. Группы оборачиваем горизонтальным AL, чтобы стояли ровно и легко сканировались. ⏹️
  5. image

— образовательный телеграм-канал об интерфейсах, продуктовом дизайне, инструментах для него, о карьере дизайнера и эмиграции Опечатки и обратную связь автору → @okunev