Назад в журнал
Про это постоянно говорят, а толку мало: внедряют единицы, а остальные продолжают гадать, что это и зачем оно надо. Последнее — исправляем.
Стыдные вопросы о дизайн-системах
Сибирикс
Стыдные вопросы о дизайн-системах
Про это постоянно говорят, а толку мало: внедряют единицы, а остальные продолжают гадать, что это и зачем оно надо. Последнее — исправляем.
Если вы погуглите о дизайн-системах, то сразу же наткнётесь на Википедию: там вам дадут общее определение, что-нибудь про атомарный дизайн, чуть-чуть о зарождении концепции 100 500 лет назад и всё такое. Потом вы пойдёте глазеть на другие ссылки с первой страницы выдачи и почитаете ещё многобукв из других источников. Но вы лучше прекращайте эти забавы с Гуглом — в этой статье всё по делу, в одном месте, коротко и ясно.
1. Окей, дизайн-система — что это?
Ждёте точное определение? Не тут-то было :) В интернетах много вариантов, но почему-то авторы боятся назвать свою версию истинно верной. Мол, чёткого понятия нет, интерпретаций — множество:

  • «это структура, которая приводит в порядок все инструменты и процессы проектирования».

  • «это набор ценностей бренда, инструментов и компонентов, который упрощает создание, тестирование, визуальное и техническое обновление продуктов, а также обеспечивает единообразие их интерфейсов».

  • «это набор правил и инструментов для визуального и технического исполнения, который отражает философию продукта и постоянно развивается».

  • «это набор компонентов, правил, предписаний и инструментов для повышения качества и скорости разработки продуктов, а также эффективной поддержки существующих».

  • «это, по сути, библиотека компонентов, которая руководствуется четким набором стандартов и руководств, и она совсем не похожа на статическое руководство по стилю, которое содержит ссылки на спецификации».

  • «это принципы, практики и технологии эффективного создания продуктов с помощью единого визуального языка, платформы сервисов и компонентов».

  • «это экосистема компонентов, интерфейсов, гайдлайнов, архитектуры и процессов, предназначенная для удовлетворения потребностей продукта или организации и достижения преднамеренных результатов».

Посмотрим на общие по смыслу слова в разных определениях: набор-система-экосистема, сервисы-компоненты, правила-инструменты-ценности, порядок-единообразие-стандарты, развивается. Короче:
Дизайн-система — упорядоченные компоненты дизайна, ценности, правила и инструменты, объединенные в систему, которая хранит стандарты, отвечает за их актуальность и легко масштабируется.
Если посмотреть на дизайн-систему с точки зрения проблем, которые она решает, то это инструмент, который помогает осознанно создавать дизайн и управлять этим процессом в постоянно изменяющихся условиях: при росте количества цифровых продуктов, увеличении размеров экранов и появлении всё новых видов устройств.
Многообразие зарубежных подходов в понимании дизайн-систем — источник.
Главная задача дизайн-систем — изменение мышления. В основе любой такой системы лежат 4 компонента: наполнение, люди, процессы и обслуживание. И если смотреть на неё с этой точки зрения, становится ясно, почему дизайн-системы никогда не стоят на месте и постоянно развиваются. И да, это сложно: потому что нужен сдвиг парадигмы от сосредоточения на результате в сторону работы над самой системой, которая лежит в основе этого результата.
Разные слои дизайн-системы по мнению Терезы Миры — источник.
2. Всё равно непонятно. Это брендбук или гайдлайн? Фрагменты кода?
И да, и нет. Брендбуки и гайды входят в компоненты дизайн-системы, но не исчерпывают их. Главная черта таких систем — масштабируемость и тиражируемость. Это значит, что с дизайн-системой команда сможет создать, скажем, сайт для автодилера в любом городе, и он будет таким же, как в любой другой точке планеты.

А значит, не будет никаких уродливых трубочек обратного звонка в разных местах на страницах, попапы будут один-в-один, как на официальном сайте, а отступы от кнопок CTA — одинаковыми. Мы ни на что не намекаем, но у Nissan, кажется, не всё гладко.
Давайте ещё раз о разнице:
Гайдлайны и стайл-гайды
Статические и не редактируемые документы

Включают «строительные блоки» и элементы дизайна, рекомендации, теории и диктуют правила и принципы использования компонентов.
Living style guides — "живые" стайл-гайды
Гайд + фрагмент кода к каждому элементу

Включают реальный пользовательский интерфейс и отображают реальные компоненты вместе с сопутствующим им кодом (настоящая кнопка плюс её поведение — например, в состоянии наведения или клика).
Целостная дизайн-система
Гайды + код + описание дизайн-процессов

Включают все дизайн-средства и инструменты, а также все руководства, описание способов работы и дизайн-процессов.
Страница из гайдлайна НАСА «Руководство по графическим стандартам»
Living style guides у Lonely Planet и Mailchimp
Полноценные дизайн-системы в открытом доступе у Salesforce Lighting и британского правительства
Справка

Немного терминов, которые вы могли встречать в определениях дизайн-систем, — чтобы вы не запутались:

  • Компоненты — это элементы интерфейса, которые формируют цифровой продукт (кнопки, поля формы, тумблеры и чекбоксы).

  • Библиотека шаблонов — набор «дизайн-шаблонов» для пользовательского интерфейса, которые состоят из компонентов дизайн-системы (например, это может быть шаблон формы онлайн-платежа).

  • Гайдлайны и брендбуки — руководства, описывающие использование логотипа компании, типографики и цвета. Это база для любой дизайн-системы.

  • Руководства по стилю (стайл-гайды) — аналогичны гайдлайнам, описывают визуальный стиль (как гайдлайны), но также могут включать редакционную политику, охватывающую стилистику текстов и тональность сообщений.

  • UI Kit — файл или документ с элементами пользовательского интерфейса (кнопки, поля формы, тумблеры и чекбоксы), используется командами дизайнеров для создания макетов и прототипов.

  • Токены (биткоины ни при чем) — основные элементы стиля дизайн-систем (например, определенные цвета бренда), управляются через централизованный файл (вроде файла JSON), который служит источником достоверности стиля для всей дизайн-системы.
3. Причём тут атомарный дизайн?
Атомарный дизайн — детище Бреда Фроста. Его идея в том, что как во Вселенной всё вокруг раскладывается на мельчайшие атомы, так и в вебе можно разложить любую страницу на микроэлементы, которые будут будут наследоваться по всему сайту.
Периодическая таблица атомарного дизайна — источник.
Идея с разложением дизайна на мельчайшие частицы отлично вписывается в концепцию дизайн-систем, которая тоже стремится к упорядоченности и тиражированию элементов всюду, где может быть дизайн. Одними из первых к дизайн-системе по такому принципу пришли в компании Гугл — тогда в 2014-м появился их Material Design. Теперь такой штукой уже никого не удивить.

Википедия говорит, что многие дизайн-системы получают собственные имена, которые отражают суть философии и визуального языка:

  • Bootstrap — фреймворк и дизайн-система Twitter.
  • Carbon — дизайн-система компании IBM.
  • Fluent — дизайн-система компании Microsoft.
  • Gel — дизайн-система компании BBC.
  • Lightning — дизайн-система компании Salesforces.
  • Material — дизайн-система компании Google.
  • Nachos — дизайн-система Trello.
  • Paradigm — дизайн-система компании Mail.RU.
  • Photon — дизайн-система Firefox.
  • Polaris — дизайн-система компании Shopify.
  • Ratio — дизайн-система компании Rambler.
  • Solid — дизайн-система компании BuzzFeed.
4. Зачем нужна дизайн-система?
Помимо очевидного примера с «одинаковостью», дизайн-системы имеют и другие преимущества:
1
упрощают и ускоряют процесс создания дизайна, и тем самым повышают его качество и эффективность;
2
оптимизируют распределение навыков — команды больше сфокусированы на UX и создании продукта, чем на том, как это обернуть в дизайн (пользователям это особенно понравится);
3
способствуют более эффективному UX и экономии на QA;
4
упрощают процесс внедрения изменений и их масштабирование внутри экосистемы бренда;
5
с течением времени становятся ценнее и требуют всё меньше усилий (чем больше компонентов внутри, тем проще работать).
Звучит неубедительно? У нас есть туз в рукаве кейс: дизайн-система для российских государственных сайтов. Ещё пару лет назад посещение сайта любого госоргана могло вызывать разные эмоции: от приступов дрожи до гнева и слёз. Потому что они были все такие разные, непонятные и пестрящие канцеляритом. Но Артём Геллер вместе с AIC основал дизайн-компанию «Смена», которая создала понятную и чёткую дизайн-систему.
Как выглядит дизайн-система для государственных сайтов РФ (публичная версия)
А вот — первые результаты применения:
Кажется, что ничего особенного? Сравните-ка вот с этим:
5. Как понять, что нужна дизайн-система?
Скорее всего, тот, кому она действительно нужна, не задаётся таким вопросом :) Потому что у него, например, большая корпорация с множеством подразделений, которые живут своей жизнью — как, например, у Альфа-Банка или Райффайзен-банка. Или у него множество цифровых продуктов, которым нужно единство — как у Яндекса. Или его цифровые продукты живут в очень разных условиях: на разных устройствах и разрешениях, а делают их разные команды — как у Иви.

Сергей Попков из AIC выделяет 4 случая, когда дизайн-система реально нужна:

  • в компании много проектов, сайтов, подразделений;
  • у компании большой корпоративный сайт со множеством сервисов и продуктов;
  • у вас есть UI-кит, но нет единой библиотеки для разработчиков и дизайнеров;
  • у бренда нет единого визуального языка.
6. Как построить дизайн-систему?
О-о-о, да вы, батенька, эстет :) А если серьёзно, начать нужно вот с чего:


1. Определиться с целями и задачами, которые решит дизайн-система

Наверняка у вас есть много наболевшего, и вы даже знаете корневые причины всех этих болей. Если нет, рекомендуем заглянуть вот сюда. На основе выявленных проблем можно строить требования к системе: какие процессы стоит автоматизировать, за счет чего, какую документацию написать, какие компоненты создать и описать… и так далее.

Дизайн-система охватывает различные аудитории: компанию и команды (определяя подход организации к дизайну, её видение и миссию), отдельных пользователей системы (владельцы продукта, UX- и UI-дизайнеры, разработчики) и конечных пользователей (люди, которые будут пользоваться итоговым продуктом).

На первом этапе также неплохо бы обсудить идею создания дизайн-системы с коллегами — дизайнерами, разработчиками и менеджерами — и донести до них её ценность. Для дизайн-команд стоит подчеркнуть, что эта система облегчит им жизнь, и продемонстрировать, насколько быстрее с ней будет дизайнить. А менеджерам, конечно, будут важнее KPI, сэкономленное время, количество команд, затронутых в краткосрочной/долгосрочной перспективе, оптимизация ресурсов и всё такое.

Культура компании должна быть зрелой, чтобы сотрудники смогли принять дизайн-систему. Если это не так, с внедрением дизайн-системы могут возникнуть бо-о-о-льшие проблемы (и чем больше компания, тем сильнее будет сопротивление).

Этот тип инициативы требует поддержки как сверху вниз, так и снизу вверх.

Дизайн-система, обычно, — этап эволюции в компании, и ему предшествует несколько уровней:
2. Определиться с тем, что уже есть

Какие-никакие гайды ваши дизайнеры точно используют. А ещё рекомендации, чек-листы, правила… Соберите всё это в одном месте, и не забудьте проверить, в каком всё это состоянии, и действительно ли сотрудники следуют этой документации.


3. Определиться с ресурсами

Речь не только о финансовых (которых понадобится предостаточно). Готовы ли вы выделить отдельную команду, которая будет заниматься созданием дизайн-системы? Кем будут эти люди? Кто их будет контролировать? Сколько времени ежедневно, еженедельно и ежемесячно вы готовы выделить для этого процесса?

Создание и поддержание дизайн-системы требует навыков: знания UX и UI, разработки, стратегии, бизнеса — есть ли они у тех, кому вы планируете доверить этот процесс?

Команда разработки дизайн-системы должна отвечать не только за создание, но и за за стандарты и целостность дизайн-системы как проекта. За ресурсы и процессы, вроде утверждения новых компонентов или оценки целесообразности введения новых компонентов и шаблонов. Она же будет участвовать в обсуждениях и получать обратную связь от тех, кто в итоге будет пользоваться дизайн-системой.


4. Разработать принципы

Обычно они отвечают на вопросы «что?», «зачем?» и «как?» — что у вас за продукт, зачем он нужен, как его используют пользователи и как должен выглядеть и работать каждый отдельный элемент дизайна.


5. Создать компоненты и шаблоны

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

Другой важный аспект — понятные названия для всех элементов: такие, чтобы были понятны и дизайнерам, и разработчикам. Здесь часто в игру вступают принципы того самого атомарного дизайна, которые помогают поделить компоненты на категории.
Компоненты мало отрисовать и описать — все эти данные должны где-то храниться и как-то передаваться. В Иви этот вопрос решили использованием формата JSON и хитростями с React, CSS и SVG. Подробнее об этом опыте — здесь.

А Фигма на днях рассказала, как создала дизайн-систему, «не отходя от кассы» — прямо в самом редакторе :)
6. Проработать документацию

По мнению Терезы Миры, хорошая дизайн-система — это основа и централизованная библиотека для тестирования и создания согласованных, эффективных и ценных цифровых продуктов. Без надежной документации это невозможно. Помимо очевидной пользы в виде «одинаковости» всех компонентов у всех дизайнеров, документация помогает адаптироваться новичкам в дизайн-команде.

Что обычно входит в документацию:

  • четкие представления о том, что можно, а что нельзя делать с компонентами и наборами пользовательского интерфейса;
  • рекомендации о том, как использовать определенные инструменты или как создавать новые UI-тулкиты;
  • рекомендации для контроля версий или создания новых библиотек;
  • рекомендации для исследования и изучения новых шаблонов.

Исключения не должны добавляться в систему (добавление бесчисленных вариаций компонента порождает ненужную путаницу, поскольку неясно, когда и какой вариант теперь использовать).


7. Учесть масштабируемость

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

При добавлении новых компонентов команда должна сопоставлять их с уже имеющимися в дизайн-системе, чтобы убедиться в применимости нововведения для всех областей (например, не только для UX и UI, но и для контента и тональности бренда).
7. Сколько времени может уйти на создание дизайн-системы?
Сложно сказать: зависит от того, в каком состоянии дизайн-процессы в вашей компании. И от размеров самой компании, конечно :) Если уже есть гайды, регламенты, какие-то прописанные правила, и налажена связь между дизайнерами и разработчиками не только на словах — будет быстрее и проще. Создавать дизайн-систему с нуля можно и год, и дольше.

Сейчас вы захотите спросить про деньги? Вопрос риторический — задайте лучше его себе: сколько вы готовы потратить на то, чтобы дизайн был согласованным, дизайнился по стандартам быстро и чётко, а любой новичок в команде делал круто с первой попытки и без косяков? Вот вам и ответ :)
Дизайн-система — это круто, но она требует много-много ресурсов и времени на создание: где-то придётся долго и нудно писать документацию, где-то — перепиливать устоявшиеся технологии. Не каждая компания к этому готова, не у каждой на это есть время, люди и деньги, поэтому только действительно крупные компании могут таким похвастать. Мой совет — не забивайте гвозди микроскопом :)

Евгений
Арт-директор
P. S. Если вас всерьёз заинтересовала тема, делимся с вами электронной книгой от Adobe и Idean о дизайн-системах.