Дизайн Системы

Привет! Меня зовут Кир. Я – Head of UI в компании Марфатех, руковожу департаментами Дизайна и Фронтенда с точки зрения общей стратегии и эффективной синергии.

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

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

Что такое Дизайн Система?

Для начала стоит упомянуть, что существует великое множество Дизайн Систем. На сегодняшний день это практически стандартное решение в любой более-менее крупной IT-компании:

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

Также, если спросить дизайнера, разработчика и менеджера, то скорее всего будут получены 3 ответа вроде бы об одном и том же, но с разных ракурсов. От загадочных понятий UI Kit и Storybook до экономии ресурсов и переизобретении неких велосипедов.

Если спросить лучшего друга человека, то мы получим довольно ёмкое определение:

Далее мы разберёмся насколько это понятно, и даёт ли ответы на все вопросы.

Каков жизненный цикл Дизайн Системы?

Представим, что у нас есть Идея. Продукт, проект, отдельная “фича” – не суть важно. От Идеи до собственно её реализации можно нарисовать следующий производственный жизненный цикл:

Условно и обобщённо, но для наших целей в самый раз:

1. Идея – бизнес-цель.

2. Прототип – валидация идеи, в самом широком смысле. От наброска на салфетке и до wireframes или даже user story.

3. Дизайн – работа над макетами.

4. Разработка – работа над реализацией.

Теперь представим, что таких идей-проектов-фич в компании две:

Исторически, как и для наглядности на нашей схеме, команды разработки первыми начинают пытаться переиспользовать какие-то общие для всех вещи:

В частности, общие компоненты, которые как детальки Lego™ могут быть использованы для построения тех или иных композиций в пользовательском интерфейсе:

Набор подобных компонентов принято называть “UI Kit”.

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

Важно отметить, что на данном этапе нет официально ответственных лиц за UI Kit. Всё построено на энтузиазме отдельно взятых разработчиков, которые полуофициально и время от времени занимаются компонентами:

Но, как показывает практика, долго так продолжаться не может, и встаёт первый вопрос направления стрелочек:

В какой-то момент до этого слабо контролируемая песочница должна превратиться в источник компонентов (и правды) для остальных команд:

Это не значит, что команды не могут использовать свои локальные, более уникальные компоненты, но всё жё в первую очередь стоит обращать внимание на набор уже существующих.

Пунктирные стрелочки здесь и далее обозначают канал обратной связи для более контролируемого и взвешенного влияния на UI Kit.

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

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

Но так или иначе, на уровне дизайна зарождается такой же UI Kit, как и в разработке.

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

Как и в случае с разработкой, UI Kit на данном этапе становится песочницей, только уже на уровне дизайна. Добавим эмодзи для большей наглядности:

Рано или поздно встаёт закономерный второй вопрос направления стрелочек:

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

Однако, это ещё не всё:

Для полноты картины мы всё же должны прийти к так называемому “design first” принципу, согласно которому дизайн первичен, а разработка это просто зеркальное отражение того, что нарисовано в макетах:

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

В таком виде всё это уже можно назвать “Дизайн Система”:

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

Они ещё не знают, что официальная “команда” влечёт за собой как определённые возможности дальнейшего развития Дизайн Системы, так и обязанности, которые практически отсутствовали на этапе полуофициальной песочницы в серой зоне:

В минимальном варианте команда Дизайн Системы обычно состоит из менеджера, дизайнера и разработчика:

Главной задачей новоиспечённой команды является непрерывная борьба за баланс между переиспользованием уже существующих компонентов и добавлением новых.

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

Объяснение границ, соблюдение процессов и интеграция Дизайн Системы во все команды становится ежедневной работой.

Так что же такое Дизайн Система?

Если оценить только UI Kit, изолированно от всего остального, то мы находимся где-то на границе между “однородностью” и “слаженностью”:

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

Дизайн Система же, развивая идею, интегрирует UI Kit в компанию для достижения единой цели, выступая как сплочённый процесс.

Давайте попробуем это сформулировать:

Дизайн Система – это набор принципов, стандартов и компонентов, встроенных в оргструктуру и процессы компании для создания единого и последовательного пользовательского интерфейса.

Т.е. не каждый open source UI Kit в вакууме по умолчанию является Дизайн Системой до того момента, пока он действительно не является частью компании.

А что дальше, после Дизайн Системы?

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

Чем масштабнее развиваются проекты компании, тем больше команд начинают использовать Дизайн Систему. Их может быть и 2, и 10, и 50.

Для описания дальнейшего шага развития Дизайн Системы обратимся к концепции Брэда Фроста под названием “Атомарный дизайн“:

По началу компоненты “атомарные” – простые и неделимые (например, обычное поле ввода). Затем компоненты становятся всё более и более “молекулярными” – чуть более сложными композициями атомов (например, поле ввода с календарём для выбора даты). С развитием Дизайн Системы “молекулы” всё чаще объединяются в “организмы” – композиции ещё более высокого порядка (например, целая форма, состоящая из полей ввода и кнопки сохранения).

Любопытное замечание, что “токены” – низкоуровневые свойства, упомянутые ранее, в этой концепции по сути являются субатомными частицами.

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

Например, во время прототипирования:

Назовём это “паттерны”:

• навигацию в наших продуктах мы делаем через сайдбар

• в шапке у нас поиск и точка входа в профиль пользователя

• форма регистрации у нас состоит из таких полей

• ошибки мы отображаем вот так

• а динамическую загрузку виджетов вот так

• …

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

Если пойти ещё дальше, то можно предположить, что между Идеями также может возникнуть некая взаимосвязь: общие мысли по повышению конверсии, вовлечённости, удобства пользования и доступности информации.

Во главе нашей схемы поставим великий термин UX – User Experience, во всём его многообразии. На результаты работы UX-специалистов могут опираться бизнес-аналитики (BA), стоящие за переводом бизнес-целей на язык требований. И наоборот.

UX привносит смыслы в паттерны, отвечая на вопросы зачем и почему мы создаём именно такие интерфейсы:

Это то, что я бы назвал “DesignOps” – ещё более абстрактный и редкий термин:

Полноценная вертикаль процессов, сопровождающая бизнес-цель от идеи до реализации с точки зрения пользовательского опыта и интерфейсов.

Итого

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