Дизайн Системы
Привет! Меня зовут Кир. Я — Head of UI в компании Марфатех, руковожу департаментами Дизайна и Фронтенда с точки зрения общей стратегии и эффективной синергии.
Эта статья расскажет о том, что такое Дизайн Системы. Не какая-то конкретная Дизайн Система от конкретной компании, а в общем и целом. Термин не самый простой, и, на мой взгляд, слишком уж абстрактный.
Я же попробую обобщить свой богатый опыт работы с различными Дизайн Системами и представить понимание о том, что же это такое с довольно интересного ракурса: через жизненный цикл и роль в оргструктуре компании.
Что такое Дизайн Система?
Для начала стоит упомянуть, что существует великое множество Дизайн Систем. На сегодняшний день это практически стандартное решение в любой более-менее крупной IT-компании:
Для кого-то это так называемый «стайлгайд», для кого-то «айдентика», а для кого-то это просто набор реиспользуемых компонентов.
Также, если спросить дизайнера, разработчика и менеджера, то скорее всего будут получены 3 ответа вроде бы об одном и том же, но с разных ракурсов. От загадочных понятий UI Kit и Storybook до экономии ресурсов и переизобретении неких велосипедов.
Если спросить лучшего друга человека, то мы получим довольно ёмкое определение:
Далее мы разберёмся насколько это понятно, и даёт ли ответы на все вопросы.
Каков жизненный цикл Дизайн Системы?
Представим, что у нас есть Идея. Продукт, проект, отдельная «фича» — не суть важно. От Идеи до собственно её реализации можно нарисовать следующий производственный жизненный цикл:
Условно и обобщённо, но для наших целей в самый раз:
Идея — бизнес-цель.
Прототип — валидация идеи, в самом широком смысле. От наброска на салфетке и до wireframes или даже user story.
Дизайн — работа над макетами.
Разработка — работа над реализацией.
Теперь представим, что таких идей-проектов-фич в компании две:
Исторически, как и для наглядности на нашей схеме, команды разработки первыми начинают пытаться переиспользовать какие-то общие для всех вещи:
В частности, общие компоненты, которые как детальки 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» — ещё более абстрактный и редкий термин:
Полноценная вертикаль процессов, сопровождающая бизнес-цель от идеи до реализации с точки зрения пользовательского опыта и интерфейсов.
Итого
В целом, во всех компаниях и проектах, в которых я строил Дизайн Системы и их команды, паттерн развития примерно один и тот же. Понимание жизненного цикла и дальнейших шагов позволяет избежать распространённых ошибок. А понимание вариантов встраивания в оргструктуру и процессы компании — это легкодоступное обоснование с точки зрения бизнес-ценностей.
