Paradigm 2.0 — как мы переосмыслили дизайн-систему Mail.ru
Про дизайн-системы сказано и написано уже многое. Дизайнеры прошли долгий путь от обсуждения шаблонов в Sketch к компонентам в коде, а от компонентов — к рамкам в дизайне и границам системности. В этой статье мы расскажем не о том, как создавать дизайн-системы, а о том, как с ними жить: что делать, если система больше не работает, как пересобрать ее заново и как «продать» ее коллегам.
Дизайн-система Mail.ru появилась в 2015 году. У нас была цель оптимизировать обновление линейки продуктов, и мы изначально затачивали Paradigm именно под эту задачу.
Мы сфокусировались на максимальной универсальности: адаптивность, переиспользуемые компоненты, связь дизайна и кода. Для этого были созданы основные принципы дизайн-системы, базовая документация, UI-киты, дизайн-токены и компоненты. Про это много раз рассказывал Юра Ветров (jvetrau), а Андрей Сундиев (ASundiev), который отвечал за развитие дизайн-системы в те годы, написал статью.
Основным принципом Paradigm на старте была идея, что системность превыше локальной оптимизации. Она отлично работала в начале, когда нужно было делать редизайн для множества продуктов за раз. Но как только продукты начали активно развиваться по отдельности, каждый в соответствии со своими возможностями и стратегией и со своей скоростью, принцип перестал нам помогать. Возможностей Paradigm стало недостаточно: изменились условия, а у нас появились новые требования.
Проблемы унификации
В первой версии дизайн-системы любое изменение влияло сразу на несколько продуктов. Например, изменение межстрочного расстояния в Новостях могло развалить типографику в настройках аккаунта Почты.
На старте жесткие правила отлично сдерживали хаос, но со временем они стали предметом горячих споров для дизайнеров. Продукты развивались с разной скоростью, и у многих из них появились специфические потребности. Кроме того, руководители продуктов все чаще слышали, что их идеи и предложения нельзя реализовать, так как они не согласуются с правилами дизайн-системы. Естественно, это вызвало рост недоверия к Paradigm.
Мы все чаще стали сталкиваться с ситуациями, когда команда проработала хорошее локальное решение, но быстро внести его в дизайн-систему невозможно. Чтобы сделать решение универсальным, нужно было проверить его для всех проектов и элементов, где есть похожий сценарий. Это занимало очень много времени: встречи затягивались, а принятие решений усложнялось. Думаю, любой, кто имел опыт работы с дизайн-системой, существующей не первый год, хоть раз сталкивался с чем-то подобным.
Проблемы технологий
Мы возгалали большие надежды на единую библиотеку компонентов для фронтенда, но со временем поняли, что у этой идеи тоже есть несколько ощутимых минусов.
У всех проектов были разные запросы: Новостям были нужны адаптивность и возможность работать с различными медиаформатами, Почте — темы оформления и инструменты для создания тулбаров и форм. Чтобы быстро развивать и поддерживать такой сложный фреймворк, нужна была большая команда разработки, но ресурсов на нее не было.
Кроме того, на тот момент команды разработки использовали разные технологии, имели специфические технические ограничения и процессы.
Хорошим решением для нас тогда стали дизайн-токены, которые до сих пор помогают нам синхронизировать параметры дизайн-системы для разных продуктов.
Проблемы доверия
Несмотря на все технические и процессные сложности, основной проблемой Paradigm оказалось недоверие к ней. Руководителям продуктов не хотелось использовать систему, потому что она накладывала много ограничений и делала разработку дизайна новых интерфейсов медленной и сложной. Дизайнеры же не всегда пользовались Paradigm, так как новые решения было сложно утверждать.
Постепенно продукты начали создавать свои локальные решения, не обсуждая их с другими участниками дизайн-команды. Со временем этих решений становилось больше и больше.
Кажется, что это длинный список проблем, но на самом деле они все возникали из одной предпосылки: мы пытались ответить на все вопросы одним универсальным инструментом.
От тактики к стратегии
Чтобы определить новую стратегию дизайн-системы, мы обратились к фундаментальному вопросу: что для нас значит Paradigm сегодня? Перебрав все технические плюсы, связанные с оптимизацией, мы поняли, что дизайн-система должна быть удобной для дизайнеров, гибкой для менеджеров и их продуктов, понятной для разработки — и вдохновляющей.
Нам важно:
- создавать бесшовный пользовательский опыт,
- дать дизайнерам удобный инструмент для работы,
- быстро проводить эксперименты в интерфейсе,
- оптимизировать разработку и дизайн стандартных задач.
Когда сами дизайнеры относятся к инструменту без энтузиазма, пропадает его смысл. Дизайн-система должна быть удобной и понятной для людей, которые с ней работают. Если правило логично выглядит в теории, но с ним невозможно работать на практике, мы отказываемся от такого правила или локализуем его.
Так мы сформировали новые дизайн-принципы.
Интересы продукта — на первом месте. Дизайн-система существует для того, чтобы делать продукты лучше. Принципы унификации не должны конфликтовать с продуктовыми решениями и потребностями бизнеса.
Общие правила для бренда, локальные — для групп продуктов. Общие правила помогают сохранить узнаваемость бренда, а локальные — быстро решать типовые задачи.
Гибкие параметры кастомизации. Параметры должны учитывать потребности продуктов, а уникальные решения должны локализовываться в рамках продукта или группы продуктов, а не исключаться из дизайн-системы.
Новый визуальный язык
Скажем честно, такая техническая вещь, как дизайн-система, интересна не всем. Иногда ее нужно «продавать», в том числе через визуальный язык. Одним из неочевидных инсайтов было то, что «красивые картинки» вдохновляют не только дизайнеров, но и менеджеров и разработчиков. Поэтому мы решили обновить визуальный стиль и все коммуникации для дизайн-системы.
Например, концепт-арты на обложках UI-китов в Figma Community — необязательный элемент, однако они служили эстетическим ориентиром для дизайн-команд и менеджеров. Дизайн-система — это далеко не всегда про красоту, но именно через красоту мы начали возвращать доверие к Paradigm.
Помимо стандартов качества графики, нам было важно заложить в визуальный язык наш подход к дизайну продуктов. Мы много рефлексировали над ним в технических иллюстрациях и активно пользовались наработками с хакатона по сайту design.mail.ru, который мы запустили в прошлом году. Так у Paradigm появился свой уникальный визуальный язык.
Уровни синхронизации
Ослабив контроль над изменениями, мы дали дизайнерам и менеджерам возможности для креатива и собрали немало запросов и инсайтов. Но если бы такая практика продолжалась и дальше, то поддерживать целостность в хаосе стало бы невозможно.
Для решения этой проблемы мы ввели уровни синхронизации между продуктами.
Глобальный: правила, которые помогают поддерживать целостность восприятия бренда.
- Брендинг
- Палитра
- Шрифты
- Иконки
- Редполитика
Нам важно формировать единое ощущение от бренда. Когда пользователь переходит от одного продукта компании к другому, он не должен видеть разные сайты с одним лого. Брендинг не заканчивается на логотипе, поэтому визуальный язык и правила работы с ним общие для всех.
Локальный: правила, актуальные для групп продуктов.
- Сетка и лейаут
- Паттерны
- Настройки типографики
- Навигация
- Базовые компоненты
Мы разделили продукты на две группы — «продуктивность» и «медиа» — и ввели для них локализованные правила. Например, паттерны потребления контента на разных медиапроектах Mail.ru похожи, так что их логично проектировать по одним и тем же принципам.
Уникальный: правила, актуальные для конкретного продукта.
- Локальные иллюстрации
- Локальная типографика
- Расширенная палитра
- Локальный 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.
