Хаос-хаос и в продакшен, — или когда вашей команде необходим аудит дизайн-системы

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

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

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

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

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

3. Утопия — своего рода IDE для владельца продукта. Если команду разработки рассматривать как систему, с помощью которой продакт проверяет свои гипотезы, то в теории такую систему можно максимально упростить — вообще выкинуть из нее дизайнеров и разработчиков, передав их функции некой среде разработки. Такой среде не нужно договариваться самой с собой, все договоренности уже вшиты в нее изначально. В некоторых компаниях (Uber, Яндекс, Альфа-Банк) уже сейчас тестируют и используют инструменты автоматизации, «снижающие трение» при передаче макетов в разработку. Сейчас такие инструменты нацелены на то, чтобы автоматизировать интерпретацию — шаг, на котором допускается больше всего ошибок. Когда такие инструменты станут стандартом, станет возможным создание полноценной «продуктовой IDE» вместо продуктовой команды (понятно, что при этом усилия разработчиков и дизайнеров будут перенаправлены на работу над такими IDE). А пока можно стремиться к такому подходу, выстраивая процессы и по возможности автоматизируя уже выстроенные.

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

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

Компании с либеральным стилем управления создают наиболее подходящую среду для появления хорошей дизайн-системы с такими процессами — выделяется время для инноваций внутри организации, не связанных напрямую с продуктом (например, по принципу «80/20»), формируются сильные гильдии дизайна и разработки, у которых есть ресурсы и мотивация развивать процессы и стек. Именно эти гильдии и эскалируют вопросы, связанные с качеством. Грубо говоря, гендиректору не нужно контролировать внедрениефич и корректировать дизайн. Если же вопросами, которые мы задавали в начале статьи, приходится заниматься именно бизнесу, есть вероятность, что проблема в том числе с дизайн-системой. Вот что они могут значить.

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

• Время разработки новых фич только растёт? — Скорее всего, не отстроена работа с техдолгом, дизайн-долгом и продуктовым долгом. Продукт копит легаси из невыстрелевших гипотез или фич, которые вроде работают, но не доведены до состояния minimum viable product, а времени на «генеральную уборку» и систематизацию решений командам не дают.

• Большая текучка в командах разработки, несмотря на адекватные условия? — В продуктовых командах, возможно, нарушена коммуникация или отсутствует возможность делать продукт, которым хочется гордиться. Хаос давит на команды и мешает делать им по-настоящему хороший продукт. Эту проблему, впрочем, можно решить с помощью дизайн-системы лишь отчасти — когда речь идет об HR-процессах, мы переходим в область дизайн-практики.

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

• Вы сами видите, что продукт выглядит и работает не так, как хотелось бы? — Туда же.

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

Важные вопросы:

• Каковы планы бизнеса на ближайшие год, три, пять?

• Входят ли в них запуск новых продуктов, глобальная переработка текущих, ребрендинг или что-то похожее?

• Готовы ли вы быстро проверять гипотезы и отказываться от кода, если он не выстреливает?

• Что для вас важнее: быстрый рост или качество?

• Для вас первична оптимизация ресурсов, или вам ближе увеличение штата?

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

• Высокое влияние. Такая система состоит из низкоуровневых (цвета, шрифты, кнопки, поля ввода и т.д.) и высокоуровневых сущностей (готовые для переиспользования флоу). Она подразумевает юзабилити-тесты, выбор необязательно дешёвых, но качественных решений, а также отслеживание использования в разработке именно элементов дизайн-системы и запрет на кастомизацию.
• Низкое влияние. Такая система состоит только из низкоуровневых сущностей. Здесь в приоритете автоматизация разработки и масштабируемость, дизайн вторичен. В таком случае не требуется использование исключительно дизайн-системы.
  

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

Важные вопросы:

• Сколько сотрудников в продуктовых командах? Сколько дизайнеров, сколько разработчиков? Есть ли планы по увеличению или сокращению штата?
• Кого вы нанимаете — и в дизайне, и в разработке? Готовых высококвалифицированных специалистов подороже или джунов? В какой пропорции?
• Удерживаете ли вы сотрудников?

  Есть ли у вас аутсорсеры? Насколько они интегрированы в продуктовый процесс?

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

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

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

Важные вопросы:

• Какие метрики используются в продукте?

• Как процесс выглядит сейчас? Насколько он устраивает?

• Кто и как ставит задачи, как оценивается результат?

• Каков состав команд? Каково распределение ролей?

• Есть ли культура гильдий? Насколько они влиятельны?

• Как устроена работа с техдолгом, дизайн-долгом и продуктовым долгом?

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

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

• Code-driven означает, что макеты — это условные чертежи, разработчики организуют компонентную базу системы так, как удобно им, а релизят тогда, когда скажет PO.

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

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

Если у гильдий дизайна и разработки уже есть достаточно свободы, ресурсов и мотивации внутри структуры (те же “80/20”), бизнес просто не задаётся вопросами о дизайн-системе. Так что, если вы задумались, а нужен ли вам подобный аудит — сигнал, что здесь и сейчас у компании нет экспертизы для того, чтобы объективно оценить это.

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

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

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

Мы в Madebymad накопили множество кейсов в консультировании команд самого разного размера. Свяжитесь с нами на [email protected] — мы поможем вам по-новому взглянуть на вашу дизайн-систему и вместе выжмем из нее максимум.