UXPUB

UXPUB - спільнота з 4,056 дизайнерів та креативних фахівців

Місце для обміну досвідом та дискусій навколо індустрії

Зареєструватися Увійти
Cover image for Все о нейминге в Figma
crypton
crypton

Опубліковано

Все о нейминге в Figma

Перевел первую статью в своей жизни, не кидайтесь сильно помидорами)

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

В этом статье я хочу поделиться своим подходом к неймингу и надеюсь, что эти советы помогут вам, если вы не знаете, с чего начать!

Нейминг

Image description

Команды, проекты и имена файлов

В Figma есть два основных способа организовать все созданные файлы: проекты (Projects) и команды (Teams). Один из подходов, который мне помог, состоит в том, чтобы представить проекты как папки, в которых хранятся файлы, а команды — как способ собрать и хранить все эти папки в более крупных группах. Хорошо, что в Figma на основе поискового запроса в результатах поиска отображаются все файлы, проекты и файлы сообщества. Однако, поскольку не существует концепции файловых тегов (пока 🤞), поисковый запрос должен быть довольно точным, чтобы найти правильный файл. Если файл называется «Onboarding», а я ищу «signupflow», шансы найти этот файл невелики.

Чтобы решить эту проблему, я начал называть свои файлы таким образом, чтобы указать как можно больше информации, например, номера версий и теги. Таким образом, я значительно повышаю шансы найти нужный файл. Вот шаблон, который я обычно использую: Имя файла (номер версии) [теги или ключевые слова]

Image description

Нейминг страниц

Страницы — это полезный способ разделить несколько холстов, юзерфлоу или прототипов, сохраняя при этом все в одном файле Figma. Обычно мне нравится полагаться на страницы, чтобы разделить различные части процесса проектирования, такие как сбор материалов для вдохновения, проведение исследований, создание прототипов или архивирование предыдущих итераций.

Страницы также могут быть полезным инструментом для тех дизайнеров, которые работают над дизайн-системами и библиотеками компонентов в Figma. Когда дизайнер активирует библиотеку компонентов в файле, на панели «Assets» отображаются все опубликованные компоненты, доступные для использования. Тем не менее, этот список может показаться сложным для тех, кто не знаком с именами этих компонентов. Figma добавит раскрывающийся список верхнего уровня для каждой страницы, чтобы упростить дальнейшую категоризацию областей компонентов, а создание страниц, специфичных для разных категорий компонентов, может упростить использование всей панели и библиотеки.

Совет: Названия страниц также поддерживают эмодзи! ✨💭 ⌨️

Image description

Нейминг фреймов

В предыдущей статье я писал о том, насколько полезными могут быть фреймы для всех, кто работает в Figma, особенно для дизайнеров, которые часто создают и организуют компоненты. Фреймы, созданные вокруг групп компонентов на холсте, не только обеспечивают небольшое визуальное разделение, но и позволяют еще больше организовать панель «Assets».

Например, в своем iOSUIKit для Figma, я создал четыре компонента, связанных с дизайном интерфейса ApplePay. Я поместил фрейм с названием «ApplePay» вокруг каждого из этих четырех компонентов, и теперь панель «Assets» показывает каждый из этих четырех компонентов в новом раскрывающемся списке с именем, соответствующим названию фрейма.

Image description

Чтобы сделать список раскрывающихся элементов более удобным для просмотра, я обычно делаю первую букву каждого слова заглавной и разделяю слова пробелом, даже если в имени компонента используется PascalCase. Компонент может называться «DatePicker» как в коде, так и в Figma, но, по крайней мере, для меня попытка поиска «DatePicker» в упакованном списке элементов стала немного проще и доступнее.

Нейминг компонентов

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

При создании компонентов я следовал методологии атомарного дизайна Брэда Фроста. Я часто создаю компоненты на уровне молекул, чтобы помочь составить и сформировать более крупные и полезные компоненты организма или шаблона (хотя они отличаются от базовых компонентов!). Поскольку эти молекулы редко функционируют сами по себе, я добавляю символ подчеркивания (например, «StatusBar») в начало имени компонента, чтобы предотвратить его публикацию и совместное использование в Командной библиотеке. Несмотря на то, что теперь это частный компонент, Figma по-прежнему позволяет ему быть вложенным экземпляром в любом другом опубликованном компоненте. Это круто!

Что касается названий этих вспомогательных компонентов, я рекомендую добавлять название компонента, где эта молекула в конечном итоге будет жить (если возможно), за которым следует дефис и имя фактической молекулы, написанное с использованием camelCase. Я делаю это потому, что при использовании компонента легко увидеть, какие вложенные экземпляры были созданы для конкретного компонента, а какие могут иметь более широкие варианты использования.

Image description

В приведенном выше примере есть компонент с именем «Calendar», а внутри — несколько компонентов на уровне атомов и молекул. Каждое имя начинается с подчеркивания, за которым следует имя «Calendar» и, наконец, дефис с добавленным именем «dayRow», обозначающим конкретное имя этой молекулы. Поначалу этот метод может показаться сложным, но по моему опыту наличие такой структуры хорошо масштабируется с библиотекой и создает очень предсказуемые имена. Также я обнаружил, что согласование имен компонентов и вариантов в Figma с тем, что отражено в коде, может оказать общее положительное влияние. Любая возможность сблизить дизайнеров и разработчиков всегда ощущается как большая победа!


Перевод статьи joeyabanks.substack.com

Обговорення (0)