Как создать дизайн-систему, которой пользуются
Токены, компоненты, состояния и правила обновления: как связать дизайн-систему с разработкой и избежать библиотеки, которая отстаёт от продукта.
Редакция ecomvision
2 мин
Опубликовано
Обновлено
Что важно запомнить
- 01Начинайте с повторяющихся сценариев действующего продукта.
- 02У компонента должны быть состояния, ограничения и пример применения.
- 03Изменения в библиотеке и коде требуют одного понятного процесса.
Сначала инвентаризация, потом библиотека
Соберите несколько реальных экранов и отметьте повторения: поля, таблицы, уведомления, навигацию. Разделите намеренные различия и случайные отклонения. Не стоит проектировать десятки вариантов кнопки, если продукт использует три.
Для первой версии системы выберите сценарий, который команда регулярно меняет. Например, формы в кабинете или карточки каталога. Польза станет видна в конкретном релизе, а не в количестве страниц документации.
Токены выражают назначение
Цвет ошибки, основной текст, фон поверхности и акцент действия должны иметь смысловые имена. То же относится к типографике, отступам и движению. Тогда смена темы или корректировка контраста не превращается в ручную замену сотен значений.
Разделяйте исходную палитру и назначение. Название «основной текст» помогает выбрать правильное значение лучше, чем «серый 700». При этом система должна допускать обоснованные исключения, а не запрещать любую новую композицию.
Компонент — это договор о поведении
Опишите не только внешний вид, но и клавиатуру, состояния загрузки, ошибку, длинный текст и запрет действия. Укажите, какие данные принимает компонент и кто управляет состоянием.
Макет и реализация должны показывать одинаковые варианты. Если дизайнер рисует недоступное в коде состояние, а разработчик каждый раз придумывает его заново, библиотека не решает задачу.
- Когда компонент подходит и когда нужен другой.
- Какие состояния обязательны.
- Как выглядит пример с настоящими данными.
- Как проверить доступность.
Назначьте владельца изменений
Запрос на новый вариант должен содержать проблему и пример. Решение может быть разным: расширить компонент, собрать композицию или оставить локальное исключение. Не каждую особенность одного экрана нужно превращать в глобальный API.
Записывайте несовместимые изменения, порядок обновления и срок удаления старого варианта. Оценивайте систему по повторному использованию и сокращению разночтений между командами, а не по размеру каталога.