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

в 12:16, , рубрики: design system
Мультипродуктовая дизайн-система: как сделать так, чтобы она реально работала - 1

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

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

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

Меня зовут Анастасия Кабалкина, я руковожу дизайном направления FinOps в VK Tech. В этой статье мы с вами разберем проблемы мультипродуктовых дизайн-систем и попробуем их решить небольшой доработкой архитектуры. А если не решить, то хотя бы минимизировать :)

Пять проблем мультипродуктовых дизайн-систем

Проблема первая: «Вас много, а я одна», или невозможность закрыть потребности разных продуктов одной дизайн-системой

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

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

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

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

Обычная мультипродуктовая дизайн-система

Обычная мультипродуктовая дизайн-система

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

Проблема вторая: неэффективность процессов работы с компонентами

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

Процесс взаимодействия продукта с дизайн-системой по вопросам разработки/доработки компонентов

Процесс взаимодействия продукта с дизайн-системой по вопросам разработки/доработки компонентов

Если в дизайн-системе предусмотрен процесс контрибьютинга (inner-source-разработки), то продукт, которому нужен компонент, разрабатывает/дорабатывает его сам напрямую в дизайн-систему. 

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

Проблема третья: перманентное увеличение нагрузки на команду дизайн-системы

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

Проблема четвертая: утрата продуктовой экспертизы на уровне дизайн-системы

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

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

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

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

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

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

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

Иерархическая дизайн-система

Решение (или хотя бы минимизация) перечисленных выше проблем — это изменение архитектуры мультипродуктовой дизайн-системы на иерархическую. 

Иерархическая мультипродуктовая дизайн-система

Иерархическая мультипродуктовая дизайн-система

Первый уровень — дочерние дизайн-системы (ДДС)

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

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

  • B2B-продуктов; 

  • B2C-продуктов; 

  • продуктов отдельной тематической линейки — например, финансовых продуктов, социальных сетей; 

  • продуктов с нативными компонентами;

  • сайтов/лендингов и т. п. 

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

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

Второй уровень — метауровень (родительская дизайн-система)

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

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

Управление иерархической дизайн-системой 

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

Структура управления иерархической дизайн-системой

Структура управления иерархической дизайн-системой

Метауровень (уровень родительской дизайн-системы)

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

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

  • лидер по дизайну и UX; 

  • лидер по исследованиям;

  • лидер разработки, тестирования и автоматизации;

  • лидер по идеологии и принципам построения и функционирования дизайн-системы. 

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

Уровень дочерней дизайн-системы

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

Эти роли ключевые, поскольку именно на уровне дочерней дизайн-системы происходит основная оперативная работа: проектирование и внедрение компонентов, шаблонов и типовых интерфейсов, формирование и переиспользование продуктовых UX/UI-паттернов, а также организация взаимодействия и обмена информацией с метауровнем дизайн-системы.

Уровень отдельного продукта

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

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

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

Плюсы и минусы иерархической дизайн-системы

Плюсы

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

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

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

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

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

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

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

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

  8. Внедрять иерархическую дизайн-систему проще и дешевле: если брать за основу дочерних дизайн-систем уже имеющиеся в компании дизайн-системы, то использующие их продукты не пострадают при переходе и не потеряют в эффективности (или пострадают в той части, в которой будет необходимо довести дизайн-систему до состояния «дочерности»).

  9. Упрощается задача объединения существующих дизайн-систем: объединение происходит не в одну дизайн-систему, а в несколько дочерних дизайн-систем, что уменьшает совокупный объем задач на объединение и позволяет распределить их между несколькими командами дочерних дизайн-систем.

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

Не минусы, но и не плюсы :)

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

  1. Некоторое усложнение структуры управления. 

  2. Необходимость постоянного наблюдения за параллельным развитием дочерних дизайн-систем.

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

  4. При присоединении существующих продуктов к дочерним дизайн-системам все равно, хотя и в меньшем объеме, возникнут задачи на объединение компонентов и кодовых баз.

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

Заключение

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

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

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

Идея создания иерархической дизайн-системы экспериментальная, поэтому, если у вас есть аналогичный опыт, аргументы за и против, идеи более удачного наименования (вместо «иерархическая дизайн-система») или просто интерес к этой теме, то поделитесь ими, пожалуйста, в комментариях.

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

* Имеется в виду закон, сформулированный в теории решения изобретательских задач (ТРИЗ), в соответствии с которым моносистемы, исчерпав свои ресурсы на моноуровне, объединяются в би- или полисистемы. Это способствует повышению эффективности систем и за счет самого факта объединения, и за счет увеличения различия между входящими в них элементами (в нашем случае — между дочерними дизайн-системами).

Благодарности

Спасибо руководителям, дизайнерам и фронтенд-разработчикам VK Tech за внимание к такой интересной теме, Саше Шаталову за человеческую и техническую поддержку во всех начинаниях, Матвею Брыксину за хорошие идеи и реальные примеры, подтверждающие верность выдвинутых гипотез, и моей команде (Насте Михальковой, Карине Мулкамановой, Нате Нефедьевой и Оле Останиной) за помощь в подготовке этой статьи.

Автор: kabalkins

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js