Токены в дизайн-системе: что это и зачем они нужны?
Токен является самой маленькой, но очень важной частью любой дизайн-системы. В этой статье я на пальцах вам расскажу для чего они нужны и как их использовать.
Представь, что ты собираешь IKEA-шкаф. У тебя в инструкции написано: «Возьмите винтик A14 и соедините с деталью F3». Всё логично и понятно — ты берешь нужные детали и соединяешь. А теперь представь, что вместо этого там написано: «Ну… возьмите винтик и соедините его с другой деталью». Какой деталью? Какой винтик? Если их десятки в коробке… Тоже самое относиться и к дизайн-системам.
Каждый элемент вроде бы есть, но никакой системы — чистый хаос. Разные оттенки, отступы у каждого блока свои, типографика отличается — будто все подобрано наугад. И в итоге интерфейс теряет целостность, а у пользователя возникают вопросы и начинает полыхать в районе пятой точки.
Можно сказать дизайн-токены — это стандартизированные кубики LEGO, из которых собираются все другие компоненты твоего интерфейса и дизайн-системы. И, что круто, эта система работает не только для тебя, но и для всей команды. Но важно не просто знать, что такое дизайн-токены, но и уметь правильно с ними работать.
Что это вообще такое?
Дизайн-токены — это простые переменные, которые описывают стили элементов в интерфейсе: цвета, размеры, отступы, шрифты, тени и т.д. Это как «строительные блоки» — из них собирается весь дизайн.
Примеры токенов в дизайн-системах
Например, вместо того чтобы в заливке каждого компонента писать «#1A73E8», ты используешь color-primary, и все понимают, что это твой фирменный синий. Сегодня он синий, а потом ты решил освежить стиль и поменять его на бирюзовый — и не нужно бегать по миллиону экранов в проекте, искать, где используется этот цвет и заменять вручную. Меняешь один токен — и всё подстраивается под новый цвет, благодаря наследованию.
Это особенно важно в больших проектах и дизайн-системах, где десятки людей работают над интерфейсом. Без токенов каждый может потянуть одеяло в свою сторону: у одного тень 4px, у другого 6px, кнопки где-то округлые, где-то с прямыми углами. А с токенами — всё стандартизировано, удобно и быстро. Потому что они:
- Спасают от бардака: ещё раз повторю это. Ты точно видел такие интерфейсы, где несколько кнопок — и все как-будто немного разного цвета. Или межстрочное у текстов везде чуть-чуть, но отличается. И это было не креативное решения, а просто неумение работать с дизайн-системой. Дизайн-токены решают эту проблему: один цвет — один токен. Без ситуаций «ну это почти такой же цвет».
- Идеальны для редизайна: нужно поменять брендовый цвет? В условиях до изучения дизайн-токенов, ты ищешь и меняешь его во всех местах ручками, тратя на это 100500 часов. Но с токенами — достаточно обновить значение одного токена, и всё обновится само и везде.
- Упрощают работу с разработкой: ты говоришь: «Здесь primary color». Dev смотрит в токены и использует эту переменную. И все счастливы, без лишних действий и вопросов: «А вы точно тот синий вставили?..»
- Ты выглядишь как профи: теперь ты не просто дизайнер, который «рисует крсивенькие картинки», ты тот, кто мыслит на пару шагов вперед. Ведь использование дизайн-токенов показывает не только твой детальный подход к дизайну, но и хорошее дизайн-мышление.
Звучит это достаточно сложно, понимаю, на самом деле так и есть. Дизайн-системы это отдельная сфера в дизайне. И в компаниях есть даже целые отделы, которые занимаются только дизайн-системой. И не дай бог, вы в компании, сделаете движение которое не соответствует дизайн-системе, дизайн-полиция, уже за вами выехала. И дабы избежать ареста, нужно шарить за дизайн-системы, поэтому давайте разберемся какие бывают токены.
Какие бывают токены?
Сразу скажу, четких правил в формировании дизайн-систем и группировки токенов, нет. В каждой компании/команде они свои. Вы сами можете изучить открытые дизайн-системы, например, Material Design от Google или Carbon от IBM, и вы заметите, что дизайн-системы строятся по разным принципам. У нас на курсе «Профессия UX/UI дизайнер», кстати, преподает спикер из IBM, который работает напрямую с дизайн-системой Carbon.
Но есть условные правила, по которым делятся токены. В основном выделяют 3 уровня токенов: базовые, семантические и контекстуальные. Рассмотрим каждый из них подробнее.
Базовые токены (base tokens)
Это самые базовые и «чистые» значения в дизайн-системе. Можно сказать, это как палитра красок, линейка и типографические значения (высота строки, межбуквенное, шрифт и т.д.) — то, из чего потом собирается весь визуальный стиль интерфейса. Их ещё называют по-разному: глобальные, опции, варианты или референсы — но суть одна. Это просто данные без контекста: цвет #1A73E8, размер шрифта 16px, отступ 4px, и так далее.
Примитивные/базовые токены
Эти токены не зависят от того, где и зачем они используются. Это просто «кирпичики», из которых потом строятся кнопки, карточки, поля и всё остальное.
Семантические токены (semantic tokens)
А вот это уже про смысл. Мы даем понятное и адекватное название, например, сolor-primary, нашему цвету #1A73E8. Т.е. Говорим, что: «вот этот набор символов с хештегом — теперь цвет кнопки».
Семантические токены
Такой подход делает дизайн-систему не только более читаемой, но и супер гибкой. Потому что если однажды тебе надо будет сменить синий на фиолетовый (ну, бывает), ты не будешь лезть по всему проекту вручную — достаточно изменить значение в одном токене. Всё остальное обновится само.
Важно лишь одно: семантические названия должны быть четким и понятным, чтобы передавать суть, например brand-color, secondary-color.
Контекстуальные токены (Contextual tokens)
Контекстуальные токены — это те самые значения, которые описывают точные параметры конкретного элемента интерфейса. Они задают, как именно должна выглядеть кнопка, форма, карточка или состояние компонента. Такие токены сохраняют индивидуальные настройки — цвет фона, радиус скругления, отступы — всё, что делает элемент уникальным.
Контекстуальные токены
Чтобы не разводить хаос, эти токены чаще всего ссылаются на базовые или семантические токены. Это помогает поддерживать консистентность и быстро вносить изменения по всей системе, благодаря наследованию.
Иерархия токенов: кто за что отвечает
Чувствую ваш вопрос, «А зачем нам вот это разбиение на уровни, разве нельзя просто обозвать какой-то токен, brand color, и использовать его везде?» Можно. Но только если ты проектируешь какой-то маленький лендосик. А если речь идёт о масштабном проекте, где сотни компонентов, несколько цветовых тем, разные платформы, возможно разные бренды и целая команда дизайнеров и разработчиков — тут уже нужна структура и логичная система.
Иерархия токенов на примере цвета заливки кнопки
Зачем это всё? Такая многоуровневая структура — не просто ради эстетики. Она помогает изолировать изменения: если тебе нужно сменить оттенок основного цвета, ты меняешь его в одном месте, а обновляется весь интерфейс. Это как иметь центральный пульт управления стилем: ничего не ломается, всё подконтрольно, и твоя система не превращается в кашу. Так же при помощи токенов и переменных адаптируют интерфейсы, мы делали подобную адаптацию в одном из уроков нашего бесплатного курса Figmaster.
Урок Figmaster “Переменные в Figma — шаг к мощной дизайн-системе”
Советы для нейминга токенов
Названия токенов — как названия улиц: если они странные и нелогичные, потом никто не разберётся, где живёт. Хочешь, чтобы твоя дизайн-система была понятной не только тебе, но и команде через полгода? Тогда нейминг — это не просто слова, а карта твоей визуальной логики.
Названия должны быть понятными
Даже если открыть ваш проект через полгода, названия должны оставаться понятными всем. Не называй токен color5, потому что через неделю ты уже забудешь, что это вообще было. Цвет кнопки? Тень ошибки? Фон tooltips?
Например, color5, padding1, text-small — непонятно, где это используется, зачем и можно ли менять. А вот color-bg-primary, spacing-button-vertical, font-size-caption — сразу видно, где применяется токен и в каком контексте.
Следуй структуре
Важно сразу определить структуру нейминга — и строго её придерживаться. Структуры нейминга в разных дизайн-системах будут разными, стандартизированных правил нейминга не существует, т.к. дизайн-системы могут преследовать разные цели.
Вот один из примеров нейминга, можно идти по схеме: категория – элемент – состояние. Такой подход помогает поддерживать порядок и предсказуемость в проекте. Хороший пример: color-bg-primary-hover, spacing-card-padding-horizontal. А вот так, bgColor1, hovered, paddingx, textBig называть не советую.
Чёткая структура не только облегчает командную работу, но и экономит ваше же время. Потому что потом не придётся вспоминать, как вы назвали отступ у той самой карточки в третьем экране проекта.
Не привязывайся к конкретному значению
Названия токенов не должны напрямую описывать, что именно там лежит — например, font-size-24px. Потому что завтра вы захотите увеличить размер шрифта — и придётся переименовывать всё в проекте.
Лучше использовать абстрактные и более универсальные имена, которые отражают не конкретное значение, а его роль в интерфейсе: color-text-error, font-size-heading-xl, spacing-content-small.
Добавляй контекст, если нужно
Если токен используется в очень специфическом месте — лучше это указать. Не всегда достаточно просто написать color-primary, особенно если у вас таких «primary» в разных компонентах штук десять. Важно, чтобы из названия было понятно, где именно этот токен используется и за что он отвечает. Так ваш будущий вы (или другой дизайнер/разработчик) не будет ломать голову: «А это вообще к чему относится?»
Например, если у вас есть кнопки с разными состояниями, то color-button-primary-hover будет гораздо понятнее, чем просто color-hover.
Дизайн-токены — это про порядок
Это про то, чтобы ты мог легко управлять своим интерфейсом, делать редизайны за полдня и не бояться, что всё развалится при первом клике. А ещё — это про уверенность. В себе, в макете и в том, что ты не просто создаешь, а выстраиваешь целую систему.
