company_banner

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.
    Mail.ru Group
    Строим Интернет

    Комментарии 1

      0
      Paradigm в современном понимании дизайн-системы (компоненты в коде) начался в 2012-2013 году, а не в 2015 — www.smashingmagazine.com/2015/02/product-design-unification-case-study-mobile-web-framework.

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

      Это не так. Токены и идея тематизации появились в 2017 году как ответ на вопрос «как не делать всех однояйцевыми» — habr.com/ru/company/mailru/blog/333510 (эта статья, кстати, цитируется выше). Т.е. иметь возможность той самой локальной оптимизации.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое