Разработка единого визуального языка для всех продуктов компании — опыт Mail.Ru Group

Дизайн-команда поделилась своими наработками в области унификации всех продуктов.

Несколько лет портальная дизайн-команда Mail.Ru Group занимается обновлением и унификацией продуктов. У нас сформировалась дизайн-система, на которой работают медиапроекты, мобильный веб и частично productivity-сервисы, появился стиль пиктограмм и иллюстраций, стандартизируются промописьма и промосайты.

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

Мы делали много подходов к «снаряду»: писали спецификации, собирали единый исходник (UI Kit), делали библиотеки элементов и так далее. Но в 2012 году поняли, что это тупиковое направление: дизайн часто «перевирается» на пути из макета в реализацию, поэтому важно переосмыслить неэффективную цепочку «гайдлайн → макет → вёрстка → реализация».

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

В нашем подразделении «Почта и портал» около 20 продуктов: производительность («Почта», «Облако», «Календарь», «Mail.Ru для бизнеса»), медиапроекты («Авто», «Гороскопы», «Дети», «Добро», «Здоровье», «Леди», «Кино», «Медиатор», «Недвижимость», «Новости», «Погода», «Спорт», ТВ, Hi-Tech, SEOSan), BeepCar, «Ответы», мобильные проекты (myMail, Artisto), главная страница и общепортальные правила для Mail.Ru, поддержка стилистики бренда My.com.

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

А есть и вовсе стоящие особняком My.com и BeepCar, которые никак не связаны с брендом Mail.Ru, но они тоже выиграют от использования общих наработок.

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

Как сделать дизайн-систему масштабируемой? Наш путь был достаточно извилистым. В 2012 году мы начали переработку мобильного веба: нужно было обновить и запустить с нуля 12 сервисов. Первым делом принялись за гайдлайны и UI Kit, но уже в ходе работы над вторым проектом осознали, что такими темпами далеко не уедем — будем весь год рисовать одни и те же макеты.

Вместе с разработчиками пришли к идее распространяемых компонентов, в которые интегрирован дизайн. Так родился наш первый фреймворк и основа для всей дизайн-системы. А перерисовку 12 мобильных сайтов мы закончили всего за 2,5 месяца — таких рекордов мы еще не ставили.

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

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

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

Именно тогда окончательно сформировалась идея параметрической дизайн-системы, которая за счёт нескольких «слоёв абстракции» (общие параметры → общие компоненты → конкретные экраны) стала достаточно гибкой и мощной. Спустя пару месяцев после начала этого процесса Google анонсировала Material Design, и мы увидели реализацию многих из наших идей на практике —  мы двигались в правильную сторону.

Текущее видение целостной дизайн-системы мы описали в 2015 году, и с тех пор постепенно его реализуем.

Что такое дизайн-система в нашем понимании:

Ключевые принципы нашей дизайн-системы, которые помогают добиться масштабирования:

Расскажем об этих принципах на конкретных примерах.

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

Все размеры и начертания шрифтов мы храним в переменных, которые используем в нужных ситуациях. Есть несколько больших групп: заголовки, наборный текст, подписи. Для нашей кнопки мы применим миксин @fontBody, который содержит в себе базовый стиль текста для productivity-сервисов. Это набор из размера шрифта, начертания, межстрочного расстояния. Если необходимо, указывается цвет и межпараграфное расстояние.

Каждый элемент дизайн-системы строится по модулям в 4dp (density independent pixels). Это значит, что все размеры элементов интерфейса и отступы между ними должны делиться на четыре без остатка. Это дополнительный «скелет», который вместе с основной сеткой для вёрстки экрана даёт гармонию в поведении элементов, а также накладывает некоторые ограничения в работе.

Значит, меньше шансов совершить ошибку. Это удобно и при работе с мобильными интерфейсами, ведь аналогичная модульная восьмипиксельная сетка используется в Google Material Design.

Для формирования отступов в нашей кнопке мы воспользуемся комбинацией из нескольких переменных: $sizeControlHeight (высота элемента) и $paddingControlButton (внутренний отступ внутри кнопки).

Все, кто работал над унификацией дизайна, знают: невероятно сложно создать минимальный набор серых цветов. А если нужны декоративные решения вроде границ, пиши пропало — набор переменных будет постоянно расти.

Как создать фиксированный и небольшой набор цветов, но при этом решать разнообразные продуктовые задачи? На помощь приходят не только переменные, но и чуть более сложные функции (mixin), а также работа со свойством прозрачности.

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

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

Для нашей кнопки мы зададим стиль обводки, который как раз использует прозрачность 0,12 и толщину линии 1px. Цвет обводки будет смешиваться с основным фоном без необходимости вводить новый цвет; переменная — $colorBorder. Также добавляем кнопке радиус скругления с помощью переменной $sizeBorderRadius.

Вторая проблема с состояниями элементов: обычное состояние, наведение и нажатие в нашем подходе предполагают дополнительные цвета заливки объекта. Учитывая многообразие акцентных цветов на медиапроектах, количество переменных может бесконечно расти.

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

Для фона кнопки мы задаём основную заливку серым цветом за счёт переменной $colorBgSecondary.

Затем используем миксин, который будет затемнять кнопку по наведению на 4%.

Чтобы получить стиль нажатой кнопки, снова применим миксин — он будет затемнять основной фон уже на 8% от стандартного. Нам также нужно увести кнопку в другую плоскость (z-index: -1) — для этого убираем тень внизу и добавляем внутри.

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

На Z-оси у нас есть четыре положения элементов:

В кнопке мы применим параметр $zIndex1.

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

Например, возьмем простую кнопку, используемую в «Почте Mail.Ru».

Поменяв параметр для фона, мы можем легко получить главную кнопку с акцентным цветом Mail.Ru.

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

Та же самая кнопка после подстановки других переменных на проекте My.com выглядит так:

Для мобильных версий сайтов кнопка становится ещё крупнее, чтобы в нее было легко попасть пальцем.

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

Начав внедрение дизайн-системы в 2012 году, в 2015 году мы сформировали её целостное видение. Она предполагает наличие единого источника правды, в котором будут чётко прописаны все правила, необходимые для создания интерфейсов. Принципы, рекомендации, конкретные гайдлайны — всё это должно храниться в одном месте и быть на 100% актуальным.

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

У нас есть такие гайдлайны, но довести их до публичного состояния пока не было возможности. Описывать гайдлайны скриншотами — тупиковое направление (они моментально устаревают и не имеют даже простейшего взаимодействия), а считать дизайн-системой UI Kit в Sketch или Photoshop — самообман.

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

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

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

Получившийся набор элементов стал образцом, на который мы ссылаемся в процессе обновления разработчиками библиотеки компонентов. По мере этого обновления мы будем заменять статичные элементы и компоненты на настоящие (взятые из библиотеки, использующейся на боевой вёрстке), и гайдлайн станет полностью живым.

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

Публикация текущих наработок — приятная веха в развитии дизайн-системы. Но впереди немало работы:

#Интерфейсы