{"id":13506,"url":"\/distributions\/13506\/click?bit=1&hash=27fcb5113e18b33c3be66ae079d9d20078d1c30f1b468cdc86ecaeefa18446c2","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0442\u0432\u043e\u0440\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438? \u0410 \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0451\u043c?","buttonText":"\u0423\u0436\u0435 \u043d\u0430\u0448\u043b\u0438","imageUuid":"2c16a631-a285-56a4-9535-74c65fc29189","isPaidAndBannersEnabled":false}
Дизайн
VK

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.

0
13 комментариев
Написать комментарий...
Exey Panteleev

В статье на Хабре больше деталей, хотелось бы и в этой статье больше иллюстраций: например рамки «креатива» в новой редакции дизайн-системы. 

Ответить
Развернуть ветку
Панда Ву

Лучше поздно чем никогда. Шеф-дизайнеру жирный респект за блестящий продакшн.

Ответить
Развернуть ветку
Sasha Ermolenko

Спасибо, передам команде 💙

Ответить
Развернуть ветку
Vladislav

Как макет слева превратился в реальность, куда пропали сексуальные тенюшки и размытия? :( 

Ответить
Развернуть ветку
Тёма Диденко

Как и написано в статье, что выносили концепт-арты на обложки, чтобы показать крутость проекта, вдохновить участников. Собственно, первая картинка – обложка,  а снизу – утилитарная реальность) 

Ответить
Развернуть ветку
Kostya Zubanov

Для Paradigm был выбран достаточно утилитарный стиль, потому что он легко масштабируется на документации и передаёт ощущение визуального языка продуктов. На страницах документации, UI-китах и так далее использованы как раз эти приёмы. Например https://paradigm.mail.ru/icon_style 
Картинки с объёмами и текстурами используются только в коммуникациях, подачах и так далее

Ответить
Развернуть ветку
Небольшой браслет

Выглядит круто ибо команда мейлару сильна, не поспоришь.
Но что самое ахрененное, превьюха со всеми свечениями и субтенями сделана только в Фигме! Я был уверен, что это 3дшый рендер. Прикиньте, чего Фигма могет!!  :-0 

Ответить
Развернуть ветку
Artem Kobyakov

фигма смогла, а фронтенд не смог повторить)

Ответить
Развернуть ветку
Username

а почему? это именно невозможно так или не хватает скиллов?

Ответить
Развернуть ветку
Yury Vetrov

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

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

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

Ответить
Развернуть ветку
Kostya Zubanov

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

Ответить
Развернуть ветку
Artem Kobyakov

спасибо, что хранишь историю! 

Ответить
Развернуть ветку
Artem Kobyakov

на сетку 4px перешли?

Ответить
Развернуть ветку
Читать все 13 комментариев
null