Сегодня дизайн-система — это неотъемлемая часть процесса разработки цифровых продуктов. Однако не всегда очевидно, как именно такой инструмент помогает работать с UI-компонентами и улучшать качество продукта.

Меня зовут Артур Иванов, я тимлид B2B Product Design департамента Design & Research Office (DRO) «Лаборатории Касперского», и именно перед нашей командой встал вызов по внедрению дизайн-системы под названием Hexa UI в уже существующие рабочие процессы отдела дизайна.

Забегая вперед: c этой задачей мы отлично справились, так что мне есть, чем поделиться ;) В статье покажу, что у нас было до внедрения, как именно мы ее интегрировали и, как итог, в чем помогает наша дизайн-система Hexa UI. Полезно будет не только дизайнерам, но и фронтендерам, и вообще всем, кто причастен к разработке продуктов.

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

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

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

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

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

3. Увеличение скорости доставки. Внедрение дизайн-системы позволяет один раз спроектировать и создать компонент, а затем — многократно использовать его в разных проектах и кейсах, а при необходимости централизованно дорабатывать.

Что было раньше

Я пришел в «Лабораторию Касперского» в 2022 году — тогда команда продуктовых дизайнеров работала с несколькими UI-китами. В наследство от предыдущих коллег также остался набор процессов и подходов, эффективность которых никто не оценивал. В самом начале работы я провел ряд интервью с дизайнерами, чтобы понять, как они используют текущие дизайн-артефакты, с какими болями сталкиваются при разработке макетов и так далее. У многих встречались одинаковые и распространенные проблемы.

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

2. Неясна наполненность библиотек. Были случаи, когда в одной из библиотек есть нужный компонент, а в другой — нет (хотя по логике должен был быть), из-за чего поиски подходящей библиотеки могли отнимать много времени. Также не было понимания, в каком статусе готовности находится тот или иной компонент: есть ли он в коде или это просто концепт?

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

К чему это приводило

Давайте теперь посмотрим, к чему это приводит, когда в отделе больше 20 дизайнеров, компания параллельно развивает 40+ B2B-продуктов, в которых порой необходимо реализовать сложные пользовательские сценарии с нелинейными пользовательскими путями.

Всё это порождало:

• большое количество локальных библиотек у каждого из дизайнеров;

• дубликаты компонентов, которые выглядели одинаково, но немного отличались друг от друга поведением в интерфейсе;

• лишние трудозатраты на смежные задачи (поиск компонентов, изучение документации), которые могли бы пойти на продуктовые.

Решения

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

Боль номер один: непонятно, что и где лежит

Мы решили перейти от разрозненных UI-китов к централизованной дизайн-системе (ее мы и назвали Hexa UI). Все релевантные для продуктовых дизайнеров файлы переехали туда. Каждый и них получил логичное и простое название с префиксом [B2B] для понимания того, что файл относится именно к нашему направлению. Например:

[B2B] Hexa UI Core — ядро дизайн-системы. Файл в котором находится весь фундамент: цвета, типографика, отступы и так далее.

[B2B] Hexa UI Components — библиотека компонентов. Содержит только их. Документация и паттерны вынесены в отдельные файлы.

По результатам опроса, 70,6% дизайнеров ответили, что теперь им стало понятно, что и где находится, а сам интерфейс стало удобно использовать. Признаюсь, я ожидал гораздо худших результатов, потому что у нас много дизайнеров, и всем угодить, тем более с первого раза, достаточно сложно.

Боль номер два: неясна наполненность библиотек

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

• еще не приступали к разработке (переработке) данного компонента; 

• компонент находится в работе в рамках дизайн системы;

• компонент полностью готов и передан в разработку и, соответственно, сейчас происходит этап перевода из дизайна в код;

• компонент готов и полностью синхронизирован с кодом (так называемая «зеленая зона»);

• дополнительный тег-статус того, что у компонента есть полноценная документация.

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

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

Боль номер три: непонятно, что когда использовать

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

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

По итогу 94,1% опрошенных ответили, что общая документация по компонентам стала понятной, но, справедливости ради, большинство сочло, что тут все еще есть, что улучшить :)

Что получилось

А теперь посмотрим на итоги внедрения Hexa UI с другой стороны. Раньше загрузка продуктового дизайнера, исходя из результатов опросов о времени решения каждой задачи, в среднем распределялась так:

• от 50 до 60% времени на задачу;

• от 20 до 25% на отрисовку компонента, которого не было в библиотеке;

• от 15 до 20% на поиск примеров в макетах других дизайнеров.

После интеграции дизайнер стал тратить:

• 80% времени на свою задачу;

• не более 10% на отрисовку своего компонента;

• от 10 до 15% на поиск похожих решений в макетах других дизайнеров.

Как вы видите, у дизайнеров высвободилось около 30% времени для решения продуктовых задач. Еще отмечу, что скорость сборки макетов выросла примерно в 1,4 раза, а количество вопросов по использованию всех этих инструментов от дизайнеров сократилось примерно в 3 раза.

Подводные камни внедрения дизайн системы

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

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

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

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

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

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

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

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

Ну а если вы хотите узнать преимущества работы с нашей дизайн-системой Hexa UI в «Лаборатории Касперского» изнутри, присоединяйтесь к нашей команде Design & Research Office :)