Что такое дизайн-система
Дизайн-система — это совокупность визуального языка (UI-kit с атомарным подходом), гайдлайнов (правила использования) и библиотеки компонентов (код).
Ценность дизайн-системы
Дизайн-система — это не просто набор кнопок и цветов, это фундамент, который держит весь продукт. Она избавляет от хаоса, экономит время и деньги, делает работу быстрее, а интерфейсы чище, консистентнее и удобнее.
- Визуальная однородность и однородность в коде
- Синхронизация компонентов и кода
- Единый источник правды для всех
- Ускорение работы (бизнес–дизайн–разработка)
- Лёгкость поддержки — правка в одном месте исправляет весь продукт сразу
- Чистый код — меньше дублирования, меньше багов, меньше костылей
- Быстрая масштабируемость — новые фичи легко вписываются в уже выстроенную систему
- А самое главное — экономия ресурсов в перспективе
Составные части
Бренд
- Виденье — общее представление о том, каким должен быть продукт и какие цели он преследует
- Принципы дизайна — базовые правила и подходы, которыми руководствуется команда при создании продукта
- Стиль, визуальный язык и характер — определение уникального стиля и настроения, которые должны передаваться через дизайн
- Тон голоса и гайды по написанию текстов — рекомендации по стилю общения с пользователями, включая примеры и запрещенные формулировки
- Терминология — согласованный словарь терминов и определений, используемых в продукте
- Звук — рекомендации по использованию звуковых эффектов и музыки в интерфейсе
- Тактильность и аромат — если продукт выходит за рамки цифрового пространства, указания по тактильным ощущениям и ароматам, ассоциирующимся с брендом
Лого
- Базовая версия
- Монохромная версия
- Варианты размеров
- Расположение и отступы
- Правила использования
- Что делать нельзя
Изображения
- Иллюстрации
- Фотостиль
Принципы UX
- Поведение элементов и взаимодействие
- Состояния загрузки
- Анимация
- Доступность и инклюзивность
Разработка
- Переменные, дробление и переиспользование — практики, направленные на повышение эффективности разработки и поддержки кода
- Каталог компонентов с документированным кодом
- Юнит-тестирование
- Семантика версионирования и контроль версий
- CI/CD
Дизайн токены
Дизайн-токены — это атомарные единицы стиля, используемые для хранения и управления решениями, связанными с дизайном, такими как цвета, шрифты, отступы и т. д. Они обеспечивают единообразие и упрощают обновление стилей в масштабных проектах.
- Разметка
- Микромодуль и единая система отступов — для обеспечения согласованности интерфейса, выстраивания четкой иерархии и отражения визуального языка бренда
- Сетка и брейкпоинты — для выравнивания элементов и создания гармоничного дизайна, а также база принципов адаптивности интерфейса
- Цветовая палитра
- Ахроматическая палитра — цвета белого фона и черного текста, например (вполне могут быть не чисто белыми и не чисто черными)
- Основной и дополнительный цвета — акцентный и комплементарный (в некоторых случаях второго может не быть, или может быть несколько)
- Сервисные цвета (ошибки, предупреждения и успешные действия)
- Исключение оптических искажений — это опционально, но надо понимать, что один и тот же цвет для текста, фона и линии дает разное впечатление, а также другой оттенок получается, если тот же цвет положить на темный фон
- Темная тема
- Палитра для слабовидящих
- Форма
- Стиль оформления углов плашек — скругленные / острые / со снятой фаской / другие декоративные
- Стиль для линий, графики и пр. — толщина линий, стиль пунктира, контраст и пр.
- Типографика
- Размерности заголовков и текстовых блоков и отступы от них
- Читабельность (соблюдение цветового и размерного контраста)
- Адаптивность (десктоп и мобильные устройства)
- Оформление адресных блоков, телефонов, цен и пр. — стили для специфических текстовых элементов, обеспечивая их выделение и понятность
- Размерности заголовков и текстовых блоков и отступы от них
- Иконографика
- Стиль и основные характерные черты — залитые или линейные, стиль и толщина линий, угол наклона и уровень детализации.
- Принципы построения — сетка, пропорции и перспектива
- Именование (и ключевые слова) — системы наименований иконок для облегчения поиска и использования в проекте
- Размерность — для различных случаев использования, обеспечивая их четкость и согласованность
- Уровни / слои — для создания четкой иерархии в пространстве — глубина интерфейса
Базовые компоненты
- Вкладки
- Состояния
- Поддержка иконок
- Размерность
- Управление с клавиатуры
- Адаптивность
- Бейдж
- Текстовый стиль
- Цвет
- Интерактив (если есть)
- Карточка
- Консистентная поддержка разного типа контента
- Адаптивность
- Карусель
- Разметка
- Элементы управления
- Адаптивность
- Кнопка
- Главная
- Второстепенная
- Кнопка-ссылка
- Размерность
- Реакция на наведение, нажатие и фокус
- С иконками и выпадающими вариантами
- Адаптивность
- Модальные окна и панели
- Уровень заголовока
- Оформление
- Элементы управления
- Принципы размещения контента
- Отступы
- Местоположение
- Индикаторы времени показа (при автоматическом закрытии)
- Пользователь
- Аватар
- Форма
- Размерность
- Изображение
- Инициалы / Иконка + фоновый цвет
- Статус (онлайн / офлайн)
- Аватар с подписью
- Аватар
- Список
- Маркированный и нумерованный
- Вложенность
- Интерактивность (при необходимости)
- Тултип и Поп-овер
- Оформление
- Принципы размещения контента
- Динамическое позиционирование
- Тайм-аут на отображение при наведении
- Светлый и темный варианты
- Поддержка доступа с клавиатуры
- Уведомления и тостеры
- Уровень заголовока
- Оформление
- Элементы управления
- Принципы размещения контента
- Отступы
- Местоположение
- Штабелирование
- Индикаторы времени показа (при автоматическом закрытии)
- Формы
- Гайдлайны по расположению и применению, недоступное состояние
- Поля ввода и выпадающие списки
- Обычные и сплит-поля
- Префиксы и суффиксы
- Иконки
- Лейблы
- Подсказки
- Реакция на наведение, нажатие и фокус
- Автокомплит
- Обработка ошибок
- Поведение и динамическое позиционирование раскрывающихся списков
- Управление с клавиатуры
- Адаптивность
- Чекбокс, Радио кнопка и Тоггл
- С лейблом и с подсказкой
- Список
- Смешанное состояние (в случае чекбокса)
- Ошибка
Примеры
- Gov.design (государственные системы России)
- Paradigm (Mail)
- Plasma (Сбер)
- Контур (Контур)
- IBM (IBM)
- Lightning (SalesForce)
- Atlassian (Atlassian)
- КОД — клуб отечественных дизайн-систем
- the component gallery — подборка импортных дизайн-систем
Зачем нужна дизайн-система
Дизайн-система — это не просто набор кнопок и цветов, это фундамент, который держит весь продукт. Она избавляет от хаоса, экономит время и деньги, делает работу быстрее, а интерфейсы чище, консистентнее и удобнее.
Исключает
- Разнобой в дизайне: без единого стандарта элементы интерфейса выглядят по-разному в разных частях продукта, создавая хаос.
- Постоянные переделки: при отсутствии четкой системы, «колеса и велосипеды» изобретаются заново, что отнимает время, силы и деньги.
- Долгий онбординг новых сотрудников: новичкам приходится разбираться в разрозненных макетах и коде вместо того, чтобы сразу работать.
- Ошибки в верстке: без системы компоненты копируются вручную, что приводит к багам и несоответствиям.
- Несогласованность между командами: дизайнеры, разработчики и менеджеры видят интерфейс по-разному, что вызывает путаницу.
- Зависимость от отдельных исполнителей: если специалист уходит, его решения теряются, потому что нет единого свода правил.
Привносит
- Системность: дизайн, код и продукт работают в одной экосистеме, исключая разногласия.
- Автоматизация рутинных задач: меньше ручной работы, больше времени на решение появляющихся новых задач.
- Гибкость и масштабируемость: продукт можно легко развивать и адаптировать без глобальных переделок.
- Чистый код: единый набор компонентов упрощает разработку, снижает дублирование и ошибки.
- Простота обновлений: любое изменение в дизайн-системе автоматически обновляет продукт.
- Быстрое тестирование идей: готовые компоненты позволяют мгновенно собирать и проверять новые гипотезы.
Таким образом, внедрение и развитие дизайн-системы приносит значительные преимущества, повышая эффективность работы команды и качество конечного продукта.
Когда не стоит применять
- Мало денег на старте — создание и поддержка дизайн-системы — это недешевое занятие
- Мало времени — создание дизайн-системы с нуля потребует в лучшем случае месяц до базового варианта
- Небольшой продукт — например сайт из нескольких страниц, с небольшим количеством типовых блоков и на этом всё
- Отсутствие бренда — это спорный пункт, но без продуманного бренда со стратегией коммуникаций, создание дизайн-системы займет еще больше времени
С чего начать
- Оценка необходимости дизайн-системы.
1.1. Взвесить масштаб проекта, затраты на внедрение и выгоды от стандартизации.
1.2. Если система нужна, сформулируйте ключевые цели её внедрения. - Формирование команды.
2.1. Минимум потребуются: дизайнеры, разработчики (преимущественно Front-end), продакт-менеджеры.
2.2. Назначение ответственных лиц за ведение и развитие дизайн-системы из каждой группы. - Анализ существующих компонентов.
3.1. Аудит текущего состояния UI и UX: какие элементы уже используются, какие повторяются, где есть несоответствия.
3.2. Анализ лучших практик.
3.3. Определение основных точек роста, где система принесёт максимальную пользу.
3.4. Важно: UI на этом этапе идет в топку и нужно договориться со всеми участниками процесса, что рюшечки, цвета и шрифты мы на этом этапе не обсуждаем - Определение минимального набора базовых элементов (атомов)
4.1. Скетчинг, вайрфрейминг, прототипирование, чтобы лучше понимать какую архитектуру использовать для будущих компонентов.
4.2. Атомарный подход (Brad Frost)
4.3. Создание фундамента: цвета, типографика, сетки, иконки, отступы…
4.4. Стили и переменные, чтобы в дальнейшем не менять их хаотично. - Создание более сложных компонентов.
5.1. Кнопки, карточки, модальные окна и другие элементы интерфейса.
5.2 Состояния элементов (наведение, нажатие, фокус, ошибки). - Документация и правила использования.
6.1. Принципы работы с дизайн-системой.
6.2. Гайдлайны по применению элементов и их вариаций. - Интеграция в процесс разработки.
7.1. Синхронизация дизайн-системы с кодом.
7.2. Формат хранения компонентов (например, через Figma и библиотеку компонентов в коде). - Сбор обратной связи и итерации.
8.1. Тестирование и анализ, как дизайн-система влияет на скорость работы и консистентность интерфейсов.
8.2. Систематические изменения и оптимизации.
Особенности Figma
- Ограничения (не волшебная кнопка, но лучшее, что есть пока на рынке)
- Проблемы
- Другой тип рендеринга в отличие от браузера
- Обновления Figma влекут за собой необходимость постоянной поддержки системы
- Глюки — ну куда ж без них… Приходится мириться.
- Бесплатный аккаунт для создания дизайн-систем
- Сложно, но можно. И скорее всего подойдет только для небольшого проекта, потому что будет неудобно работать с библиотекой.
- Платный аккаунт
- Позволяет создавать больше страниц (удобная структура компонентов)
- Использовать библиотеки и сквозно распространять/обновлять компоненты
- Подключать только необходимые библиотеки к новым отдельным продуктам
- Лучшие практики
- Атомарный подход
- Не блокировать слои (если на слое стоит замочек, то человек с правами view only не сможет перенести, посмотреть и пр.)
- Не засовывать иконки в вариативные компоненты (сложно потом искать и выбирать, когда они используются внутри других компонентов)
- Полезные файлы и плагины
Разработка компонентов
- Степень проработки и универсализации
- Компоненты
- Вариативность
- Именование
- Адаптивность (автолейауты и констрэинтсы)
- Интерактивность
- Сетка и модуль
- 4/8 рх vs 5/10 рх
- Настройка гридов
- Иконки
- Проблема однопиксельности
- Цвет
- Подход к подбору цветовой палитры с тонкой настройкой оптических искажений цвета
- Темная тема
- Работа со сценами (принципы и тонкости)
- Типографика
- Плюсы и минусы большого количества стилей
- Единая система отступов
Слияние и разделение дизайн-систем
- Особенности слияния
- Поглощение
- Создание новой
- Особенности деления
Создание спецификаций
- Понятность описательного языка
- Tone of voice и инфостиль
- Инфографика
- Навигация
Внедрение и работа с разработчиками
- Волшебной кнопки нет
- Создать проще, чем внедрить
- Влажные фантазии и сухая реальность
- Вовлекать разработчиков с первых этапов создания (ключевых)
- Постоянная проверка пульса и обсуждение возможностей с разработчиками на каждом из этапов
- Помним о бизнес-целях: лучше работающий сухой стандарт сегодня, чем глючный, непроверенный через неопределенное количество времени
- Начинаем с MVP, сначала жизненно необходимое и то, что точно внедрится на первых порах
- Гибкость и компромиссность — то, что не получается сейчас, внедряем на следующем этапе
- Возможные проблемы и последствия
- Пульс
- Комментарии в фигме при важных изменениях
- Важность
- Методы
- Стандартные комментарии
- Кастомные (создание вариативных компонентов в определенном стиле)
- Общий чат разработки
- Регулярные созвоны
- Все, что всплыло — заносится в гайд — если один человек задал вопрос, то скорее всего, он возникнет и у другого
- Комментарии в фигме при важных изменениях
- Влажные фантазии и сухая реальность
- Всего не предусмотреть и это нормально. Учитываешь ошибки прошлого. Появляются новые затыки. Находишь решения. Оттачиваешь. Внедряешь.
- Подрядчики
- Проблема закрытости библиотек
- Работа в других средах разработки
Библиотека компонентов
- Тестирование
- Закрытая/открытая
- Инструменты
- Storybook
- Bit
- Zeroheight
- Supernova
- Кастомные решения