В этой статье
Scott
Scott

Опубликовано 06.11.2026, обновлено 06.11.2026

Имена Frame 184 и Button Copy скрывают смысл, даже если макет аккуратен. В Pixso UI design maker проверяйте layers, components, variants и handoff одной терминологией.

Пример структуры слоёв и имён компонентов
Пример структуры слоёв и имён компонентов

1. Что должно делать имя

Имя помогает найти asset, понять роль, сохранить смысл вне исходного экрана и связать концепцию с кодом. Category и purpose помещайте в имя, а size, emphasis и state — в properties.

Не записывайте все детали в одну строку. Используйте description, документацию и examples, а затем проверьте правило на поиске, обсуждении и handoff.

2. Создайте короткую грамматику

Category / Component / Subcomponent делает Navigation / Tabs / Item и Input / Select / Option предсказуемыми. Один раз договоритесь о capitalization, separators и abbreviations.

Blue Button описывает внешний вид, а Primary Button — роль. Проверьте, что разделители не конфликтуют с поиском по slash в Pixso.

3. Называйте компоненты и variants по смыслу

Компонент получает имя по системной роли, а variant отвечает на вопросы о size, emphasis, state и положении icon. Не используйте type=one и version=new.

Один glossary применяйте к components, styles, variables и assets в Pixso, чтобы команды не переводили один смысл по-разному.

4. Пусть layer name показывает структуру

Структурный и интерактивный слой должен объяснять purpose. Label, supporting text и dismiss action переживут смену шрифта и цвета.

  • Сначала purpose, затем appearance.
  • Одинаковая роль получает одинаковое слово.
  • Slot и property совпадают с документацией.
  • История работы не попадает в public name.
  • Deprecated pattern сопровождается migration note.

5. Согласуйте tokens, assets и документацию

gray-700 и blue-500 — raw values, а не роли. Semantic tokens объясняют использование, а имена icons вроде search, download и warning описывают содержание и контекст.

Рядом с компонентом укажите допустимый content, states, способ использования и ограничения.

6. Мигрируйте библиотеку контролируемо

Не переименовывайте зрелую библиотеку одним sweep. Соберите usage, owners, duplicates и dependencies, затем сопоставьте старые и новые имена для одной family.

Pixso импортирует Figma, Sketch и Axure. После импорта проверьте variants, fonts, prototype triggers и Auto Layout; Smart Rename применяйте к ограниченным участкам и review.

7. Проведите совместный review в Pixso

Соглашение проверяйте задачами: designer находит компонент, создаёт variant и собирает экран, а developer сопоставляет его с кодом. Comment закрывает вопрос, а правило попадает в документацию.

8. Сохраните смысл в handoff

Для production component укажите design name, code counterpart, properties, tokens, states, content constraints и responsive rules. D2C делает код проверяемым, но не заменяет production implementation.

Финальный аудит

  • Имена описывают устойчивую роль, а не экран или цвет.
  • Variants показывают понятные допустимые выборы.
  • Layer names объясняют структуру и interaction.
  • Tokens раскрывают semantic role и сохраняют primitive values.
  • Search, docs и code mapping используют общий glossary.
  • Migration имеет owner, tests и deprecation guidance.

Заключение

Хорошее соглашение об именах делает design system проще для поиска, расширения, review, миграции и реализации. Держите grammar небольшой и согласуйте vocabulary в Pixso от layers до handoff.

Наверх
Поделиться в X
Поделиться в Facebook