Дизайн-система

Всем привет!

Я рад вернуться к вам, дорогие читатели сообщества, и поделиться опытом и знаниями, полученными благодаря работе в IT-компании Omega.

Тема дизайн-систем, казалось бы, уже рассмотрена со всех сторон: можно найти множество статей, постов, докладов и других материалов. Несмотря на это, у каждого, кто сталкивается с этим термином, возникает множество вопросов. Я постараюсь подробно ответить на главные из них:

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

• Для чего она нужна?

• Как её создать?

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

Давайте разбираться по порядку. Дизайн-система представляет собой совокупность трех сущностей:

1. Визуальный язык то, что мы видим.

2. Framework библиотека визуального языка, его код.

3. Guidelines правила, как должно все выглядеть и каким образом применяться.

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

Визуальный язык

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

• Цвета

• Шрифты

• Пространство

• Формы объектов

• Иконки

• Изображения

• Взаимодействия

• Анимации

• UI-компоненты

• Звуки

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

Какой образ приходит вам в голову, когда слышите или видите названия таких банков, как Альфа-Банк, ВТБ, Сбербанк, Тинькофф и других? Какие эмоции вы испытываете? Визуальный язык является одним из фактором того, каким мы запомним тот или иной продукт.

Framework

Фреймворк это, по сути, код визуального языка. Благодаря нему все визуальные элементы можно взять из библиотеки и легко применить во всех своих продуктах.

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

Что, если у нас фреймворка нет? Тогда данную кнопку необходимо создать заново, пусть даже путем копирования существующего. А если мы решили изменить цвет кнопки, то нам придется вручную менять цвет во всех подобных кнопках? А если таких кнопок десятки, сотни или больше?

Поэтому нужна централизованная библиотека элементов визуального языка, которая позволит создавать и переиспользовать каждую деталь продукта.

Guidelines

Чтобы все, кто взаимодействуют с дизайн-системой, разговаривали на одном языке, необходимо выработать правила.

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

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

• Что это за элемент?

• Где он используется?

• Какие задачи решает?

Также для UI-компонентов можно описывать анатомию: обозначьте структуру и все параметры, из которых они строятся.

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

Для чего нужна дизайн-система?

Как и для любого IT-продукта, важно ответить на вопрос: для чего нужна дизайн-система? Или, как говорят некоторые коллеги по цеху чтобы что?

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

Автоматизация

Автоматизация это самая очевидная ценность. Дизайн-система позволит автоматизировать процессы и выиграть время на другие задачи.

Например, дизайнеры смогут сформировать библиотеку компонентов в графическом редакторе Figma и применять их во всех необходимых макетах. Разработчики, в свою очередь, просто используют ранее реализованные компоненты из фреймворка.

Итеративность

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

Однако любое внесение изменений это большая ответственность. Поэтому любая коррекция должна быть сознательной и аргументированной.

Консистентность

Консистентность говорит о том, что объекты и сущности, которые мы используем в продукте и которые выполняют одну и ту же работу, должны стремиться к унификации, стремиться быть похожими.

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

Синхронизация

Все элементы в IT-продукте должны обладать единым языком общения на основе четких правил.

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

Больше времени на UX

Эта ценность является, по сути, совокупностью всех предыдущих преимуществ. Ручная работа с визуальным языком, на которую раньше тратилось много времени, становится максимально автоматизированной.

После создания дизайн-системы можно выделить больше времени на исследование и детальнее спроектировать user flow сценариев продукта (да, бывает, флоу не все делают и просто фигачат). Кстати, я писал подробно о user flow в предыдущей статье.

Скорость прототипирования

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

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

Все вышеописанное можно отнести к плюсам дизайн-систем, но у них, конечно, есть минусы.

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

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

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

Как создать дизайн-систему?

Есть множество подходов для создания дизайн-системы. Я рекомендую рассмотреть атомарную систему, главным преимуществом которой является наследуемость. Пожалуй, тема атомарной дизайн системы может потянуть на отдельную статью. Про это можно почитать в переводе статьи Брэда Фроста (Brad Frost) Atomic Web Design.

Примеры того, как сделаны дизайн системы:

• https://www.lightningdesignsystem.com/

• https://atlassian.design

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

Я надеюсь, что каждый почерпнул для себя ценное из статьи. А я еще раз убедился в том, что работа над статьей структурирует знания и мотивирует на дополнительное изучение.

Спасибо за внимание!

Рассказываю о небольшом цветовом фреймворке, который используется в нашей ДС. Сначала, как обычно, небольшой обзор бест-практисов, а затем мой велосипед. Пойдем по порядку.

Сколько нужно цветов

У нас "Заказчиками" цветов являются продуктовый дизайнер, маркетинг и разработка.

Что нужно для счастья простому дизайнеру?

Что нужно маркетингу?

Что нужно разработке?

Окей, а сколько оттенков каждого из цветов нужно? Не самый простой вопрос, между прочим.

Способ 1

Чтобы сделать один раз и хватило, обычно делают так:

Изменяя яркость и/или насыщенность с каким-либо шагом (он может быть динамическим), генерируется набор из примерно десяти оттенков каждого цвета. Два-три варианта будут использоваться часто, а остальные будут не очень часто.

Чтобы как-то проще ориентироваться какие оттенки используются только в самых красивых макетах, а какие постоянно можно сделать так:

Способ 2

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

Ну ты же видишь, что ни один из 49 оттенков серого, которые у нас уже есть, сюда не подходит, с ними выглядит плохо, нужен еще один, да, для иконки со стрелочкой, смотри как хорошо сразу стало.

Ну или наоборот, что тоже не ок:

У нас уже есть отличный брендовый красный, который мы используем для всего, почему бы не использовать его и для ошибок тоже, зачем нам еще один красный?

Способ 3

Еще можно прописывать для каждого цвета стейты. Default, hover, pressed, и т.д. Тогда цвет становится атрибутом конкретного элемента. Но для этого, как мне кажется, должно быть выполнено два условия очень ограниченное число интерактивных элементов и высокая дизайн-зрелость продукта.

Color name / DefaultColor name / HoverColor name / Disabled

Описанное выше есть в том или ином виде в любом проекте. Дальше мой велосипед.

Фреймворк

В предыдущих заметках я описывал свой подход к библиотекостроению и упоминал референсную библиотеку. У нас несколько продуктов и нужен был инструмент, который позволял бы добавлять продуктам индивидуальности. При этом хотелось бы без проблем заимствовать компоненты из одного продукта в другой без перекрашивания или, хотя бы, делая это по какой-то понятной логике.

Я разделил набор цветов на 2 части:

Основная часть одинаковая для всех продуктов. Чай.

• Base палитра серого;

• BG фон;

• Functional для всяких функциональных штук вроде ссылок и ошибок.

Дополнительная уникальная надстройка для продукта. Сахар.

• Brand цвета бренда, используемые в продукте;

• Promo акцентные цвета для всяких промо-историй.

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

Семантика

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

Для серого оказалось достаточно четырех степеней важности.

Для фона двух.

Цвета для всяких функциональных штук одинаково важны, их разделил по назначению, а не по важности.

Бренд.

У промо-цветов тоже нет каких-либо приоритетов, только названия: желтый, зеленый и т. д.

Подобного набора цветов обычно недостаточно, было решено добавить немного вариативности за счет сдвигов и градиентов. У каждого цвета может быть несколько вариантов, подчиняющихся определенным правилам, а может и не быть, если они пока не нужны.

Сдвиги

Сдвиги небольшие отклонения от основного цвета.

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

Градиенты

Для каждого цвета может быть градиент, построенный на его основе, а может и не быть. А может быть только градиент, из которого можно будет получить базовый цвет.

Инверсии

У нас нет темной темы, но часто появляется потребность разместить что-то на контрастном фоне. Например, бахнуть текст не на белом фоне экрана, а на темно-синем банере. Или, вдруг, на одном из экранов использовать не белые карточки на сером фоне, а черные на черном. Для этого используются "инвертированные" версии цветов.

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

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

Нейминг

В фигме структура следующая:

Часть фреймворка / Тип / Группа_Модификатор группы / ИмяTea / Solid / Base / Primary_Inverted / Default Sugar / Gradient / Brand / Secondary / Up

Есть мнение, что токены должны иметь одинаковый нейминг в фигме и в коде. Но не все так просто. Паттерны работы с цветом в фигме и верстке отличаются. Сделав все одинаковым, мы прогнем дизайнера и получим кривые группы цветов в фигме с которыми ему будет сложно работать. Поэтому для цветов стоит описать naming convention, которая опишет принципы по которым цвета именуются в фигме и как этот нейминг должен переноситься в код. В итоге всем должно быть ок.

Идея со сдвигами была подсмотрена в цветовой схеме Opium.Fill.

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

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

Характеристики цвета

Цвета разделяют на две категории: хроматические и ахроматические. Ахроматические это не спектральные цвета. Черный, белый, оттенки серого. Они имеют только одну характеристику светлоту.

Цветовые системы

Классификация цветовых систем:

1. По свету (RGB). Смесь. Красный, зеленый, синий

2. По краске (CMYK). Вычитание. Голубой, пурпурный, желтый, черный

На мониторах мы имеем дело со светом, поэтому разберем более подробно, что такое цветовая система света.

В 1676 Исаак Ньютон провел следующий эксперимент: пропустил луч света через трёхгранную призму и получил цветовой спектр от красного к фиолетовому, кроме пурпурного. После этого спектр был пропущен через собирательную линзу, в результате чего был получен белый цвет.

Своим экспериментом Ньютон доказал, что белый цвет не первичен и состоит из цветных компонент с разной степенью преломляемости. Эти составляющие как раз и оказались первичными. Далее он пропустил синий цвет через еще одну трехгранную призму, но синий цвет не разложился на новый спектр, что в свою очередь доказало, что этот цвет и является первичным.

Цвет света

До этого эксперимента все считали, что предметы обладают цветом. Однако, Ньютон определил что предмет при попадании на него луча света часть световых волн поглощает, а часть отражает. И в зависимости от того, с каким углом происходит преломление, таким мы и считаем цвет предмета.

Красный сосуд выглядит красным потому, что он поглощает все остальные цвета светового луча и отражает только красный.

Иоганн Гёте смешал фиолетовый и красный, таким образом, получив пурпурный цвет и появился новый цветовой круг.

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

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

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

Мишель Шеврёль был первым, кто разработал цветовой атлас. В его основе 6 основных цветов в двенадцати модификациях.

Цвет краски (Субтрактивный цвет или Subtractive color)

Эта система предсказывает спектр мощности света после прохождения света через последовательно поглощающие слои разных сред. Создателем цветового колеса при вычитаемом смешении является Моисей Харрис.

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

Какой формат использует большинство?

Еще со времен CSS 2.1 принято использовать либо HEX, либо RGB-цвета. Недостатками использования такой формы представления цвета являются:

• Система не понятна интуитивно. Мы не разделяем цвет отдельно на красный, зеленый и синий и не приводим цвет в шестнадцатеричную систему счисления, да и не говорим, например, Кремль цвета #ff0000.

• Отсутствует поддержка. Дизайнерам может понадобиться 10 типов одного цвета, а в HEX и RGB нет никакой привязки к оттенкам.

HSL (hue, saturation, lightness)

Цвет в HSL представлении определяется тремя значениями:

• тоном (оттенком, hue);

• значением (светлотой, яркостью, value);

• хромой (цветностью, насыщенностью, chroma, saturation).

Существует трехмерная колометрическая система Манселла. В ней цвет определяется с помощью трех координат.

Если составляющие цвета переименовать, мы получим следующую картину:

Выбор цветовой схемы

Темизация, white label, редизайн вот перечень основных пунктов, с которыми может столкнуться команда разработки. И чтобы эти пункты не превратились в проблемы, нужно с самого начала разработки предпринять ряд шагов.

1. Выбор типа цветовой схемы

Итак, какие же бывают цветовые схемы, согласно теории цвета:

• Монохромные (используется один основной цвет и его оттенки)

https://codepen.io/gevara2015/pen/xxVdooe

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

Всего же существует 5 цветовых схем:

1. Монохроматическая схема (один основной цвет).

2. Добавочная схема (два основных цвета).

3. Триадная схема (три основных цвета).

4. Тетраэдная схема (четыре основных цвета).

5. Примыкающая схема (два или три основных цвета).

Не будем тратить время на подробный разбор каждой схемы, это сделано вот здесь, перейдём ближе к коду.

2. Именование переменных

Большинство именований переменных цвета, которые есть сейчас: accent, base, high, button-contrast-alpha, positive, negative, faint, success, warning... множество их. И почти к каждому обозначению есть вопросы.

1. Возьмём, к примеру, high относительно чего он high, есть ли low, насколько high больше и по какому параметру low?

2. Button-contrast-alpha. Если следовать логике этого именования, должен быть ряд alpha, beta, gamma. Опять же вопрос: чем они будут отличаться и в какой степени? Какой цвет будет иметь средние значения?

3. Низкий уровень абстракции: button, text, link и т. д.

По именованию, мне кажется, нужно придерживаться ряда правил:

• Вместо alpha, beta, gamma использовать strong, base, weak.

• Primary (основной цвет бренда).

Учитывая множество абстракций в именовании (в имени переменной нельзя указывать конкретный параметр элемента разметки или сам элемент), я подумал о том, что было бы неплохо придерживаться именования по слоям (мало кто вспомнит аддон Tilt в Firefox). Чтобы отличить один элемент от другого, достаточно представить, что он находится просто уровнем выше. А чтобы он выделялся, нужно ему задать этот самый цвет подложки, что-то наподобие background и foreground.

И тут я наткнулся на объяснение принципов именования переменных для Material Design.

1. Background (0dp elevation surface overlay)

2. Surface (with 1dp elevation surface overlay)

3. Primary

4. Secondary

5. On Background

6. On Surface

7. On Primary

8. On Secondary

2.1 Разделение именований

Лучшим решением для разработчиков и дизайнеров является описание переменных и промежуточного слоя, который это все соединяет. То есть переменные для разработчиков описывают лишь отдельные свойства с привязкой на их расположение в "слоях" потока элементов. А вот переменные для дизайнеров наоборот должны быть связаны конкретно с цветом, тоном, яркостью.

https://codepen.io/gevara2015/pen/poywzLj

То есть для описания свойств элементов нам будет достаточно следующего набора переменных:

/* elements variables */--global-background: var(--bg);--surface: var(--bg-weak);--on-color: #fff;--on-background: var(--contrast-weak);--on-primary: var(--on-color);--on-secondary: var(--on-color);--on-error: var(--on-color);--on-surface-prime: var(--contrast-weak);--on-surface-second: var(--contrast-strong);--input-background: var(--bg-weak);--input-outline: inset 0 0 0 1px var(--secondary-strong);--component-outline: none;

Также стоит отметить, что для описания границ элемента лучше использовать не border, а box-shadow, так как он является более комплексным (можем применить сразу хоть три значения тени):

--component-outline: 15px 17px 26px -4px rgba(34, 60, 80, 0.6), 15px 17px 19px -11px rgba(20, 117, 191, 0.6), -22px -36px 19px -11px rgba(56, 167, 103, 0.6);

Плюс он не меняет размер всей кнопки или, к примеру, инпутау (если мы берем за исходные данные box-sizing: border-box). Мне кажется, что это является хорошим решением, так как разработчики описывают для каждого компонента набор переменных, а дизайнер в дальнейшем может играться с цветами или цветовыми схемами, с дизайнерскими подходами (skeuomorphism, neumorphism) или даже использовать LCH цвета, все на усмотрение дизайнера.

Lea Verou в своей статье указывает на вариант конвертации цветовой схемы для темной темы с помощью L (светлота) параметра в HSL формате. В итоге для светлой темы получается лесенка:

 --l-0: 0%;--l-30: 30%;--l-40: 40%;--l-50: 50%;--l-90: 90%;--l-100: 100%;

а для тёмной обратная лесенка переменных:

@media (prefers-color-scheme: dark) {:root {--l-0: 100%;--l-30: 70%;--l-40: 60%;--l-90: 10%;--l-100: 0%;}}

И казалось бы, все логично, можно просто определить текущий параметр светимости как формула 100% - lightness, и он будет средним как для темной, так и для светлой темы. Однако у hsl есть недостаток. В светлой теме будет недостаточно контраста для ряда элементов. Решение, предложенное Lea Verou c использованием LCH цветов, как мне кажется, еще слишком сырое, это все еще драфт в спецификациях w3c.

Выводы

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

2. Настройка цветовой схемы лежит полностью на дизайнере, и он отдает всего лишь итоговый файл конфиг.

3. Компания Stripe сделала инструмент для внутреннего использования в своих продуктах, но для разработки подобного инструмента нужны ресурсы.

Автор: Александр Танцюра, Frontend Developer в Space307.