Процессы vs инструменты: как устроена дизайн-система в «Лаборатории Касперского»

Поговаривают, эпоха дизайн-систем (ДС) прошла. Идея компонентного подхода и унификации провалилась. Чтобы делать хороший экосистемный дизайн, необходима лишь сильная команда и минимальный набор библиотек. Правда в том, что эпоха ДС ни наступала, ни проходила. Компонентный подход работал всегда, и дизайн здесь — не исключение.

Дмитрий Крикунов, старший визуальный дизайнер в «Лаборатории Касперского», пробует доказать это на конкретном примере из практики.

Постараюсь доказать, что без ДС в большой компании, где только в B2B-сегменте десятки продуктов, не обойтись. Я архитектор дизайн-систем в «Лаборатории Касперского». За время работы с ДС у меня сложилось определенное представление о ее преимуществах и недостатках.

Сначала попытаемся зафиксировать, что же собственно должна представлять собой дизайн-система. Это лишь отчасти про библиотеки (либы) и гайды/документацию. Когда я пытался строить свою первую ДС, начитавшись статей в интернете, то сразу направил все внимание на построение библиотек и написание доков. Но когда библиотеки были относительно проработаны, особого успеха заметно не было. Тогда я ощущал, что упускаю что-то важное. В результате проб и ошибок я пришел к выводу:

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

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

В любом другом случае такой подход будет обречен на провал. Предполагаю, что если дизайн-систематизация не складывается, это связано с недостаточным пониманием ее «всецелости».

В «Лаборатории Касперского» можно условно выделить три больших направления: B2B, B2C, KasperskyOS.

Продукты в каждом из трех направлений создаются на следующих платформах:

· B2C — Windows, iOS, Android

· B2B — WEB (React, Angular)

· KasperskyOS — WEB, Windows, Android

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

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

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

Задача крутая и масштабная. Но как ее достигать?

Я сразу понял, что либами и доками тут не обойтись. Работать нужно именно с мышлением и восприятием, осознать, что зоопарк технологий — это плохо, как и множество фронтовых UI-библиотек. Мыслить в рамках одного проекта нельзя, нужно думать про других: «Что им будет полезно?».

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

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

Напомню, у нас четыре платформы: Windows, Web, iOS, Android. Поэтому невозможно создать одну библиотеку и набор компонентов. Кроме того, у каждой платформы есть поддержка темной темы и реализована она по-разному. Дизайн-система должна быть модульной. Я искал архитектурное решение, которое позволило бы покрыть все платформы с их особенностями, сохранить единообразие визуала и не заковать дизайнеров в слишком тесные рамки при создании дизайна.

В итоге оно было найдено. У нас есть общий портал Foundation Resource, на нем представлены базовые принципы, которые используются на всех платформах и во всех проектах.

Здесь описаны базовые принципы подбора цветов, палитр, сетки, дизайн-токенов, типографики. Это кроссплатформенная база для всех библиотек.

На основе данных из Foundation Resource образуются большие модули. Глобально это B2B, B2C и KasperskyOS.

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

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

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

Пока мы собираем документацию в Storybook и отчасти в Figma. В Figma хранятся поверхностные подсказки про компонент и основные его параметры.

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

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

Успевать к релизам, сдерживать и контролировать поток задач нам помогают Team Foundation Server (TFS) или Jira. Можно использовать, например, Notion или Trello. У нас есть доска в TFS, где мы собираем заявки на добавление/изменение новых компонентов или исправление багов верстки/визуала. Еще есть несколько досок для планирования итераций по модулям дизайн-системы. Приоритеты мы выстраиваем исходя из дат релизов продуктов.

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

Каждая библиотека тесно завязана на фронтенд. Например, на Windows дизайн парсится посредством плагина напрямую из Figma в набор XML-правил. Дальше эти правила преобразуются в стилевую библиотеку, переиспользуемую на всех Windows-продуктах. Далее каждый продукт в любой момент времени может «подтянуть» к себе новые изменения.

Что касается Web, схема примерно такая же. Только дизайн мы не парсим целиком из Figma, а передаем JSON-токенами: цвета, типографику, эффекты. Потом токены идут в Storybook, где собраны все компоненты. Из компонентов, собранных в Storybook, продукты собирают свой визуал.

Обновление токенов в Storybook распространяется на все продукты, завязанные на эти компоненты. Продукт может «подтянуть» любые обновления в продакшн.

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

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

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

Пересмотр и изменение процессов под текущие реалии — самый действенный способ поддерживать ДС любого масштаба в «здравии и благополучии».

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

В дизайн-системе заложен огромный потенциал, который действительно может ускорять процесс разработки и упрощать процесс проектирования. Чтобы раскрыть этот потенциал, нужно кропотливо и много работать. А инструменты для «покорения» ДС — прежде всего не библиотека и компоненты, а процессы и взаимоотношения.