Референсы в дизайн-системе

Дизайн-система фиксирует принятые правила. Библиотека референсов хранит визуальные аргументы, альтернативы и проектный контекст, из которых эти правила появились. Связь между ними помогает объяснять и развивать систему, не превращая скриншоты в спецификацию.

Референсы появляются раньше правил

На этапе исследования команда сравнивает структуры, взаимодействия, типографическую иерархию и визуальную подачу. Большинство примеров не станет частью системы. Полезные референсы показывают повторяющуюся проблему, убедительный подход или крайний случай, который текущая система не учитывает.

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

Свяжите аргументы с решением

Для важного компонента или паттерна сохраните короткую историю:

• проблему и ограничения;
• два-три референса, повлиявших на обсуждение;
• выбранное правило и отклонённые варианты;
• известные границы и адаптивные состояния;
• компонент Figma и реализацию в коде;
• владельца и дату проверки.

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

Переводите наблюдения на язык системы

Референс может показать читаемый приглушённый текст, но повторяемым результатом станет семантическая цветовая роль. Он может подсказать ритм карточки, но системе нужны токены интервалов, ограничения контента и адаптивное поведение. Удачное сравнение тарифов должно превратиться в паттерн с состояниями и требованиями доступности.

U.S. Web Design System описывает дизайн-токены как ограниченный набор именованных решений. Референсы показывают эти решения в контексте, а токены закрепляют принятую часть.

Отделите исследование от актуального правила

Используйте разные доски или статусы для сырого исследования, шорт-листа, утверждённых прецедентов и устаревшего руководства. Старый пример может оставаться полезной историей, но не представлять текущую систему.

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

Проверяйте референсы вместе с системой

На ревью компонентов спрашивайте: существует ли исходная проблема, отражают ли примеры нужное поведение и появились ли новые языки, объёмы контента или требования доступности.

Начните с материала что дизайн-система даёт веб-дизайнеру, затем свяжите один часто используемый компонент с небольшой доской Refframe. Если следующий участник понимает и правило, и его причину, связь работает.