Paradigm 2.0 — как мы переосмыслили дизайн-систему Mail.ru

Рассказываем, как и почему менялась Paradigm — одна из первых дизайн-систем в России.

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

Дизайн-система Mail.ru Group появилась в 2015 году. У нас была цель оптимизировать обновление линейки продуктов, и мы изначально затачивали Paradigm именно под эту задачу.

Мы сфокусировались на максимальной универсальности: адаптивность, переиспользуемые компоненты, связь дизайна и кода. Для этого были созданы основные принципы дизайн-системы, базовая документация, UI-киты, дизайн-токены и компоненты. Про это много раз рассказывал Юра Ветров, а Андрей Сундиев, который отвечал за развитие дизайн-системы в те годы, написал статью.

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

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

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

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

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

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

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

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

Несмотря на все технические и процессные сложности, основной проблемой Paradigm оказалось недоверие к ней. Руководителям продуктов не хотелось использовать систему, потому что она накладывала много ограничений и делала разработку дизайна новых интерфейсов медленной и сложной. Дизайнеры же не всегда пользовались Paradigm, так как новые решения было сложно утверждать.

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

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

Чтобы определить новую стратегию дизайн-системы, мы обратились к фундаментальному вопросу: что для нас значит Paradigm сегодня?

Нам важно:

• создавать бесшовный пользовательский опыт,

• дать дизайнерам удобный инструмент для работы,

• быстро проводить эксперименты в интерфейсе,
  

• оптимизировать разработку и дизайн стандартных задач.

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

Так мы сформировали новые дизайн-принципы.

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

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

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

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

Например, концепт-арты на обложках UI-китов в Figma Community — необязательный элемент, однако они служили эстетическим ориентиром для дизайн-команд и менеджеров. Дизайн-система — это далеко не всегда про красоту, но именно через красоту мы начали возвращать доверие к Paradigm.

Помимо стандартов качества графики, нам было важно заложить в визуальный язык наш подход к дизайну продуктов. Мы много рефлексировали над ним в технических иллюстрациях и активно пользовались наработками с хакатона по сайту design.mail.ru, который мы запустили в прошлом году. Так у Paradigm появился свой уникальный визуальный язык.

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

Для решения этой проблемы мы ввели уровни синхронизации между продуктами.

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

• Брендинг
• Палитра
• Шрифты
• Иконки
• Редполитика

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

Локальный: правила, актуальные для групп продуктов.

• Сетка и лейаут
• Паттерны
• Настройки типографики
• Навигация
• Базовые компоненты

Мы разделили продукты на две группы — «Продуктивность» и «Медиа» — и ввели для них локализованные правила. Например, паттерны потребления контента на разных медиапроектах Mail.ru Group похожи, так что их логично проектировать по одним и тем же принципам.

Уникальный: правила, актуальные для конкретного продукта.

• Локальные иллюстрации
• Локальная типографика
• Расширенная палитра
• Локальный UI-кит

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

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

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

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

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

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

Хороший пример гибкого подхода в работе команды Paradigm — это UI-киты. Команда дизайн-системы создает базовые UI-киты с основными компонентами, прорабатывая не только их наполнение, но и структуру и даже оформление. Это позволяет сформировать единые дизайнерские стандарты и сохранить целостность даже в документации.

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

Со временем команда дизайн-системы накопила большой объем знаний о разных продуктах и превратилась в центр продуктовой экспертизы.

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

Мы завели каналы, через которые информируем коллег об обновлениях и запусках. Изменения в Paradigm мы активно освещаем на Mail Design Demo (мероприятии для всех дизайнеров в Mail.ru Group) и на канале в нашем корпоративном мессенджере Myteam. О крупных запусках пишем в рассылке и постах в интранете. Для всех этих активностей мы используем тот самый визуальный язык дизайн-системы.

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

Внутреннюю документацию мы ведем в Notion, а некоторые разделы из нее автоматически публикуются на сайте paradigm.mail.ru.

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

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

Мы регулярно обновляем дизайн-документацию в Figma Community, анонсируем события и публикуем вакансии на design.mail.ru, ведем страницу нашей команды в Facebook и, конечно, постим всю эту красоту, которую вы видели выше, на Dribbble.