[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Vladislava Rakhmanova", "author_type": "self", "tags": ["\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 30, "likes": 33, "favorites": 39, "is_advertisement": false, "section_name": "default", "id": "25281" }
Vladislava Rakhmanova
16 178

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

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

Поделиться

В избранное

В избранном

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

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

Предыстория

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

Дизайн до унификации

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

Контекст

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

Продукты под брендом Mail.Ru

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

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

Продукты под другими брендами

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

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

Гайдлайны в Confluence
UI Kit для мобильного веба

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

Унифицированный мобильный веб

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

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

Унифицированные медиапроекты

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

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

Наброски идеологии модульной дизайн-системы

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

Текущее состояние

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

  • Визуальный язык определяет то, как мы создаём интерфейсы продуктов. Как и в обычном языке, у нас есть алфавит (переменные), слова (элементы интерфейса), предложения (компоненты) и цельные тексты (экраны и продукты). Алфавит неизменен, словарный запас трансформируется со временем, а вот предложения и тексты из них создаются всегда разные.
  • Единые компоненты на технологическом уровне — единственный источник правды. Дизайн «вшит» в них, сервисы получают и обновляют их из единого репозитория. Продукты под брендом Mail.Ru, которые используют их на практике: медиапроекты, мобильный веб, часть productivity-сервисов. Они пока доступны только внутри компании.
  • Шаблоны для дизайнерских инструментов — лучший способ быстро показать идею. Другими словами, это просто высокоуровневые скетчи. В идеальной ситуации макеты не верстают, а собирают из единых компонентов. Мы писали об этом раньше.
Живой гайдлайн с компонентами на технологическом уровне
Шаблон в Sketch

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

  • Модульность. Позволяет сравнительно легко управлять большим количеством продуктов. Интерфейс строится по принципу слоёв абстракции: «переменные → базовые элементы интерфейса → компоненты для реализации конкретных задач → экраны продукта».
  • Параметричность. Изменение конкретных параметров, из которых строятся элементы интерфейса, позволяет добиться масштабируемости на продукты разных типов. Для этого мы используем переменные и миксины.
  • Минимум костылей. Собираем элементы интерфейса из уже существующих переменных, а компоненты — из уже существующих элементов. Любые принимаемые нами решения должны вписываться в систему, жить по её правилам и потенциально быть готовыми к применению на любом из наших продуктов.
  • 4dp — так называемый «суперпиксель» — краеугольный камень системы, на нём строится вся шкала размерностей. Мы мыслим исключительно числами, кратными четырём. Со стороны идея делить на четыре даже значения прозрачности покажется ересью, но это значительно сокращает количество споров и расхождений по любым переменным. В шрифтовой части возможны отступления, связанные с рендерингом шрифтов в Windows (размеры 13, 15 и 17), но мы надеемся побороть это со временем.
  • Адаптация под мобильные (малые экраны) и сенсорные экраны (управление пальцем, отсутствие мыши). Любые наши решения изначально должны быть touch-friendly — это касается размеров элементов, действий по наведению и тому подобного. Границы между устройствами размываются, и привычные настольные компьютеры имеют сенсорные экраны. Все интерфейсы должны быть либо адаптивными, либо иметь мобильную версию.

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

Параметричность

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

Типографика

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

Сетка и отступы по 4dp

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

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

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

Основной цвет и граница

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

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

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

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

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

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

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

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

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

@mixin stateHover ($colorBgSecondary) {

background: mix($colorBgSecondary, $colorAccent, 4%);

}​

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

@mixin stateActive ($colorBgSecondary) {

background: mix($colorBgSecondary, $colorAccent, 8%);

box-shadow: $zIndex-1;

}​

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

Положение по Z-оси с помощью тени

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

  • Элемент ниже базового уровня (например, нажатая кнопка) — вдавлен.
  • Элемент на базовом уровне (основной контент: текст, фото и иллюстрации) — лежит на основной плоскости.
  • Элемент приподнят над базовым уровнем (кнопки, карточки) — часть вёрстки или дополнительная информация к основному контенту.
  • Элемент на отдельном уровне (попап, всплывающая подсказка, меню) — способ показать дополнительный контекст без ухода из основного.

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

Что в итоге

normal:

height: $sizeControlHeight; // 32px

padding: 0 $paddingControlButton; // 0 16px

background-color: $colorBgSecondary; // #f0f0f0

border-radius: $sizeBorderRadius; // 2px

border: $sizeBorderWidth solid $colorBorder; // 1px solid rgba(0,0,0,.12)

box-shadow: $zIndex1; // 0 2px 0 0 rgba(0,0,0,.04)

color: $colorBody; // #333333

font-size: $fontBody; // 15px

line-height: $fontBodyLine; // 20px​

hover:

@include stateHover ($colorBgSecondary);​

active:

@include stateActive ($colorBgSecondary);

disabled:

opacity: .48.

Масштабируемость

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

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

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

Какие параметры меняем:

background-color: $colorAccent; // #168de2

color: $colorBody; // #ffffff​

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

Какие параметры меняем:

​height: $sizeControlHeight; // 40pxpadding: 0 $

paddingControlButton; // 0 20px

background-color: $colorAccent; // #5856d6

color: $colorBody; // #333333

border-radius: $sizeBorderRadius; // 4px

font-size: $fontBody; // 17px

line-height: $fontBodyLine; // 24px

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

Какие параметры меняем:

height: $sizeControlHeight; // 40px

padding: 0 $paddingControlButton; // 0 20px

background-color: $colorAccent; // #00abf2

color: $colorBody; // #333333

border-radius: $sizeBorderRadius; // 4px

font-size: $fontBody; // 17px

line-height: $fontBodyLine; // 24px

text-transform: $fontBodyCase // uppercase​

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

Какие параметры меняем:

height: $sizeControlHeight; // 48px

padding: 0 $paddingControlButton; // 0 20px

background-color: $colorAccent; // #168de2

color: $colorBody; // #333333

border-radius: $sizeBorderRadius; // 2px

font-size: $fontBody; // 15px

line-height: $fontBodyLine; // 20px

text-transform: $fontBodyCase // uppercase​

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

Paradigm

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

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

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

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

Визуальный язык

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

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

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

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

  • Выше скорость сборки макетов и продуктов. Можно уделить больше внимания самому продукту, а не просто рисованию экранов. В фреймворке появляется всё больше необходимых блоков и компонентов на все случаи жизни, что позволяет быстро собрать новый интерфейс. Это удобно для пользователя: группа схожих продуктов работает одинаково, понятно и привычно. А также хорошо для бренда: вся линейка сервисов выглядит целостной.
  • Улучшенное качество продуктов. Контролировать большой пул проектов проще, когда они устроены одинаково. Вместо сотни отдельных проектов вы следите за парой гайдлайнов.
  • Кумулятивный эффект от удачных продуктовых решений. Например, подняв глубину просмотра на одном из сервисов, легко применить эти улучшения на остальных.
  • Проще взаимодействие с другими командами. Аутсорсеры делают более качественные проекты, команды других продуктов не изобретают велосипед.
  • И самое главное — переход от крупных редизайнов раз в несколько лет к постоянному поддержанию актуальности интерфейса. Перезапуски отнимают много сил и теряют тысячи мелких наработок, прикрученных к дизайну за долгое время его развития.

Будущее

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

  • Перевести оставшиеся продукты на дизайн-систему.
  • Заменить псевдоживой гайдлайн на настоящий, который выводит использующиеся на продуктах компоненты. Они есть, но пока сыроваты для публикации.
  • Синхронизировать базу элементов интерфейса и компонентов. Часть из них есть только в визуальным языке, технологическим фреймворке или дизайнерских шаблонах.
  • Дополнить живой гайдлайн общими принципами взаимодействия, доступности, анимации.

#Интерфейсы

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

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

0 новых

Популярные

По порядку

Прямой эфир

Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления