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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!


Про дизайн-системы сказано и написано уже многое. Дизайнеры прошли долгий путь от обсуждения шаблонов в 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.
Источник: https://habr.com/ru/company/mailru/blog/559910/


Интересные статьи

Интересные статьи

Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию...
Предыстория Когда-то у меня возникла необходимость проверять наличие неотправленных сообщений в «1С-Битрикс: Управление сайтом» (далее Битрикс) и получать уведомления об этом. Пробле...
Если у вас есть интернет-магазин и вы принимаете платежи через Интернет, то с 01 июля 2017 года у вас есть онлайн-касса.
Несмотря на то, что “в коробке” с Битриксом уже идут модули как для SOAP (модуль “Веб сервисы” в редакции “Бизнес” и старше), так и для REST (модуль “Rest API” во всех редакциях, начиная с...
Одной из «киллер-фич» 12й версии Битрикса была объявлена возможность отдавать статические файлы из CDN, тем самым увеличивая скорость работы сайта. Попробуем оценить практический выигрыш от использова...