Дизайн-система, которая переживёт первый релиз
От кнопок в макете к работающему языку продукта: состояния, токены, доступность и правила развития.
Начните с повторяющихся решений
Дизайн-система полезна там, где команда снова и снова решает один вопрос: какой статус показать, как оформить ошибку, сколько воздуха оставить вокруг действия. Каталог красивых кнопок сам по себе этой задачи не решает.
Токены описывают смысл
Названия вроде primary и surface понятнее номера оттенка. Отделяйте цвет действия от цвета сообщения об успехе. Для тёмной темы меняйте семантические значения, а не инвертируйте весь экран.
:root {
--surface: #ffffff;
--text: #202b35;
--action: #367da8;
--focus-ring: #76b5df;
}Компонент состоит из состояний
В карточке могут отсутствовать обложка и автор. Заголовок может занять три строки. Форма бывает пустой, заполненной, ошибочной и отправленной. Покажите все эти состояния до интеграции с API.
- Фокус виден при работе с клавиатуры.
- Иконка имеет понятную подпись.
- Ошибка объясняет способ исправления.
- Длинные значения не ломают сетку.
- Снижение движения отключает лишнюю анимацию.
Документация должна помогать выбрать
Добавьте к компонентам правила применения и короткие примеры. Когда нужен акцентный вызов к действию? Сколько основных действий допустимо в форме? Как обозначить опасную операцию? Эти ответы экономят больше времени, чем ещё один вариант скругления.
Как развивать систему
Изменение компонента должно проходить через реальные экраны. Соберите несколько сложных сценариев: мобильный каталог, длинную статью, таблицу с пустыми данными. Система становится надёжной, когда выдерживает разнообразие контента, а не только идеальный макет.
Обсуждение 2
Обсуждаем идеи, делимся опытом и уважаем собеседника.
Полезный разговор начинается с вас.
Войти и обсудить ↗Как понять, что пора выделять компонент, а не оставлять его в конкретном экране?
Я бы начал с повторяющегося решения и похожих состояний. Два визуально похожих блока могут решать разные задачи — механически объединять их не всегда выгодно.