Что такое дизайн-система

Дизайн-система — это совокупность визуального языка (UI-kit с атомарным подходом), гайдлайнов (правила использования) и библиотеки компонентов (код).

Ценность дизайн-системы

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

• Визуальная однородность и однородность в коде
• Синхронизация компонентов и кода
• Единый источник правды для всех
• Ускорение работы (бизнес–дизайн–разработка)
• Лёгкость поддержки — правка в одном месте исправляет весь продукт сразу
• Чистый код — меньше дублирования, меньше багов, меньше костылей
• Быстрая масштабируемость — новые фичи легко вписываются в уже выстроенную систему
• А самое главное — экономия ресурсов в перспективе

Примеры

• Gov.design (государственные системы России)
• Paradigm (Mail)
• Plasma (Сбер)
• Контур (Контур)
• IBM (IBM)
• Lightning (SalesForce)
• Atlassian (Atlassian)
• КОД — клуб отечественных дизайн-систем
• the component gallery — подборка импортных дизайн-систем

Зачем нужна дизайн-система

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

Исключает

• Разнобой в дизайне: без единого стандарта элементы интерфейса выглядят по-разному в разных частях продукта, создавая хаос.
• Постоянные переделки: при отсутствии четкой системы, «колеса и велосипеды» изобретаются заново, что отнимает время, силы и деньги.
• Долгий онбординг новых сотрудников: новичкам приходится разбираться в разрозненных макетах и коде вместо того, чтобы сразу работать.
• Ошибки в верстке: без системы компоненты копируются вручную, что приводит к багам и несоответствиям.
• Несогласованность между командами: дизайнеры, разработчики и менеджеры видят интерфейс по-разному, что вызывает путаницу.
• Зависимость от отдельных исполнителей: если специалист уходит, его решения теряются, потому что нет единого свода правил.

Привносит

• Системность: дизайн, код и продукт работают в одной экосистеме, исключая разногласия.
• Автоматизация рутинных задач: меньше ручной работы, больше времени на решение появляющихся новых задач.
• Гибкость и масштабируемость: продукт можно легко развивать и адаптировать без глобальных переделок.
• Чистый код: единый набор компонентов упрощает разработку, снижает дублирование и ошибки.
• Простота обновлений: любое изменение в дизайн-системе автоматически обновляет продукт.
• Быстрое тестирование идей: готовые компоненты позволяют мгновенно собирать и проверять новые гипотезы.

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

Когда не стоит применять

• Мало денег на старте — создание и поддержка дизайн-системы — это недешевое занятие
• Мало времени — создание дизайн-системы с нуля потребует в лучшем случае месяц до базового варианта
• Небольшой продукт — например сайт из нескольких страниц, с небольшим количеством типовых блоков и на этом всё
• Отсутствие бренда — это спорный пункт, но без продуманного бренда со стратегией коммуникаций, создание дизайн-системы займет еще больше времени

С чего начать

1. Оценка необходимости дизайн-системы.
   1.1. Взвесить масштаб проекта, затраты на внедрение и выгоды от стандартизации.
   1.2. Если система нужна, сформулируйте ключевые цели её внедрения.
2. Формирование команды.
   2.1. Минимум потребуются: дизайнеры, разработчики (преимущественно Front-end), продакт-менеджеры.
   2.2. Назначение ответственных лиц за ведение и развитие дизайн-системы из каждой группы.
3. Анализ существующих компонентов.
   3.1. Аудит текущего состояния UI и UX: какие элементы уже используются, какие повторяются, где есть несоответствия.
   3.2. Анализ лучших практик.
   3.3. Определение основных точек роста, где система принесёт максимальную пользу.
   3.4. Важно: UI на этом этапе идет в топку и нужно договориться со всеми участниками процесса, что рюшечки, цвета и шрифты мы на этом этапе не обсуждаем
4. Определение минимального набора базовых элементов (атомов)
   4.1. Скетчинг, вайрфрейминг, прототипирование, чтобы лучше понимать какую архитектуру использовать для будущих компонентов.
   4.2. Атомарный подход (Brad Frost)
   4.3. Создание фундамента: цвета, типографика, сетки, иконки, отступы…
   4.4. Стили и переменные, чтобы в дальнейшем не менять их хаотично.
5. Создание более сложных компонентов.
   5.1. Кнопки, карточки, модальные окна и другие элементы интерфейса.
   5.2 Состояния элементов (наведение, нажатие, фокус, ошибки).
6. Документация и правила использования.
   6.1. Принципы работы с дизайн-системой.
   6.2. Гайдлайны по применению элементов и их вариаций.
7. Интеграция в процесс разработки.
   7.1. Синхронизация дизайн-системы с кодом.
   7.2. Формат хранения компонентов (например, через Figma и библиотеку компонентов в коде).
8. Сбор обратной связи и итерации.
   8.1. Тестирование и анализ, как дизайн-система влияет на скорость работы и консистентность интерфейсов.
   8.2. Систематические изменения и оптимизации.

Особенности Figma

• Ограничения (не волшебная кнопка, но лучшее, что есть пока на рынке)
• Проблемы
  • Другой тип рендеринга в отличие от браузера
  • Обновления Figma влекут за собой необходимость постоянной поддержки системы
  • Глюки — ну куда ж без них… Приходится мириться.
• Бесплатный аккаунт для создания дизайн-систем
  • Сложно, но можно. И скорее всего подойдет только для небольшого проекта, потому что будет неудобно работать с библиотекой.
• Платный аккаунт
  • Позволяет создавать больше страниц (удобная структура компонентов)
  • Использовать библиотеки и сквозно распространять/обновлять компоненты
  • Подключать только необходимые библиотеки к новым отдельным продуктам
• Лучшие практики
  • Атомарный подход
  • Не блокировать слои (если на слое стоит замочек, то человек с правами view only не сможет перенести, посмотреть и пр.)
  • Не засовывать иконки в вариативные компоненты (сложно потом искать и выбирать, когда они используются внутри других компонентов)
• Полезные файлы и плагины
  • Components by Const Lab

Разработка компонентов

• Степень проработки и универсализации
• Компоненты
  • Вариативность
  • Именование
  • Адаптивность (автолейауты и констрэинтсы)
  • Интерактивность
• Сетка и модуль
  • 4/8 рх vs 5/10 рх
  • Настройка гридов
• Иконки
  • Проблема однопиксельности
• Цвет
  • Подход к подбору цветовой палитры с тонкой настройкой оптических искажений цвета
  • Темная тема
• Работа со сценами (принципы и тонкости)
• Типографика
  • Плюсы и минусы большого количества стилей
• Единая система отступов

Слияние и разделение дизайн-систем

• Особенности слияния
  • Поглощение
  • Создание новой
• Особенности деления

Создание спецификаций

• Понятность описательного языка
• Tone of voice и инфостиль
• Инфографика
• Навигация

Внедрение и работа с разработчиками

• Волшебной кнопки нет
• Создать проще, чем внедрить
  • Влажные фантазии и сухая реальность
    • Вовлекать разработчиков с первых этапов создания (ключевых)
  • Постоянная проверка пульса и обсуждение возможностей с разработчиками на каждом из этапов
  • Помним о бизнес-целях: лучше работающий сухой стандарт сегодня, чем глючный, непроверенный через неопределенное количество времени
  • Начинаем с MVP, сначала жизненно необходимое и то, что точно внедрится на первых порах
  • Гибкость и компромиссность — то, что не получается сейчас, внедряем на следующем этапе
    • Возможные проблемы и последствия
  • Пульс
    • Комментарии в фигме при важных изменениях
      • Важность
      • Методы
        • Стандартные комментарии
        • Кастомные (создание вариативных компонентов в определенном стиле)
    • Общий чат разработки
    • Регулярные созвоны
    • Все, что всплыло — заносится в гайд — если один человек задал вопрос, то скорее всего, он возникнет и у другого
• Всего не предусмотреть и это нормально. Учитываешь ошибки прошлого. Появляются новые затыки. Находишь решения. Оттачиваешь. Внедряешь.
• Подрядчики
  • Проблема закрытости библиотек
  • Работа в других средах разработки

Библиотека компонентов

• Тестирование
• Закрытая/открытая
• Инструменты
  • Storybook
  • Bit
  • Zeroheight
  • Supernova
  • Кастомные решения