Дизайн-система не обязана быть большой. Для небольшой компании она может начинаться с простых вещей: типографической шкалы, набора цветов и нескольких повторно используемых компонентов. Главное — не размер библиотеки, а то, помогает ли она в реальной работе.
Начинать стоит с того, что повторяется
Если на каждой новой странице появляется немного другая кнопка, формы получают разные отступы, а дизайнер и разработчик снова обсуждают уже знакомые детали, система фактически уже существует. Просто она нигде не зафиксирована.
GOV.UK Design System строится на повторном использовании готовых компонентов и паттернов. Один из его принципов — начинать с уже существующих решений, а не решать одну и ту же задачу заново без необходимости.
Общие дизайн-значения
Цвет, размер шрифта, отступ и высота строки могут принимать множество значений. На практике продукту обычно нужен ограниченный набор.
U.S. Web Design System описывает design tokens как ограниченный набор значений для цвета, отступов и типографики. Это помогает сделать работу последовательнее и упростить коммуникацию между дизайном и разработкой.
Для небольшой команды это может быть одна типографическая шкала, небольшой набор отступов, определённые цвета и понятные состояния элементов.
Компоненты и их роль
Компонент полезен, когда он встречается в нескольких местах и выполняет понятную функцию. Это может быть кнопка, поле ввода, карточка, навигация или таблица.
GOV.UK рассматривает компоненты как повторно используемые части интерфейса и дополняет их рекомендациями о том, когда и как их применять. Это важная часть системы: одной библиотеки в Figma недостаточно, если команда не понимает правила использования.
Последовательность не означает одинаковость
USWDS использует принцип be consistent, not static. Дизайн-система должна давать стабильную основу, но не превращать все страницы в копии друг друга.
Небольшую систему можно развивать постепенно
Практичный старт — посмотреть самые используемые экраны, собрать типографику, цвета и отступы, стандартизировать основные компоненты и кратко описать, когда их применять.
Новые варианты стоит оценивать до того, как они становятся постоянной частью библиотеки. Главное — чтобы система использовалась в реальной работе, а не существовала только в документации.
Дизайн и код должны говорить на одном языке
Единые названия компонентов, размеров и состояний упрощают сотрудничество. Design tokens тоже могут служить связующим слоем: и дизайн, и код обращаются к одному ограниченному набору значений.
Когда дизайн-система не нужна?
Не каждому проекту нужна полноценная система. Короткой рекламной странице может быть достаточно аккуратного style guide, а небольшому сайту — понятных правил и ограниченного набора компонентов.
Ценность дизайн-системы растёт, когда что-то постоянно повторяется: много страниц, несколько продуктов, несколько дизайнеров или разработчиков, регулярные обновления.
Цель — не увеличить количество правил
Хорошая дизайн-система должна облегчать работу и делать интерфейс более предсказуемым. Для небольшой команды лучшая система редко бывает самой большой. Лучшая — та, которой действительно пользуются.