Разработка единой дизайн-системы — опыт «Рамблера»

К узнаваемому визуальному стилю удалось привести более 20 брендов компании.

«Рамблер» давно стал больше, чем сайтом. Сейчас он состоит из 20 проектов различной направленности — от тематических медиа до сервисов вроде почты или погоды.

Первая попытка глобально подойти к фирменному стилю сервисов была сделана ещё четыре года назад, ей занималась команда выходцев из «Афиши». В 2016 году «Рамблер» сменил логотип, а в 2017 появилась новая стратегия развития продуктов, направленная на объединение всех сервисов в единую платформу нового «Рамблера». Все пришло в движение: обновились команды, открылись новые проекты. Структура самого портала и сервисов вокруг него усложнялась, а требования к скорости разработки росли.

До изменений в стратегии сервисы «Рамблера» развивались самостоятельно, отрабатывая каждый свои задачи. Связи между командами были скорее формальными, каждый продукт мог иметь свой уникальный интерфейс, что заставляло пользователей привыкать к одним и тем же элементам заново.

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

Перед отделом дизайна стояла задача за год разработать новый визуальный язык для более чем 20 разных продуктов, создав в сознании пользователя устойчивую ассоциацию с единым брендом нового «Рамблера». Без серьезной оптимизации по всем фронтам было не обойтись — так мы пришли к необходимости разработки собственной дизайн-системы.

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

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

Первичной стала заповедь: сначала вы работаете на дизайн-систему, а потом она работает на вас. Если второго не происходит, нужно задуматься.

Ключевыми принципами для разработки новых компонентов стали:

Гибкость и потенциал для эволюции — это то, что помогает формировать правила, а не конкретику, которую потом тяжело поддерживать.

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

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

Наша дизайн-система состоит из трёх основных частей:

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

Sketch-файлы мы храним в корпоративном Dropbox, доступ к которому имеют все участники команды разработки системы. Здесь же хранятся все ассеты и файлы, необходимые для работы с дизайном продуктов, в том числе и внешняя рекламная коммуникация.

Компоненты разрабатываются на GitLab, публичная их часть доступна на GitHub.

До появления единого описания каждый сотрудник представлял себе миссию, ценности и стратегию развития «Рамблера» в меру своей (испорченности) информированности, если, конечно, вообще знал о таких вещах.

Такие абстрактные понятия, как философия бренда, на первый взгляд, находятся слишком далеко от дизайна. Но когда мы столкнулись с необходимостью объяснить большому количеству людей внутри компании, почему тот или иной элемент сделан именно так, то на себе ощутили необходимость в единых формулировках. Бренд-часть в составе дизайн-системы нам очень помогает.

Именно поэтому бренд в нашей дизайн-системе занимает место концептуального ядра. Речь о верхнеуровневых ценностях компании, в соответствии с которыми работает весь комплекс правил и инструментов дизайн-системы, включая собственный стиль бренда и интерфейсы.

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

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

Чем отличается визуальный язык от гайдлайнов? Это части одного целого. Но если визуальный язык описан на уровне концепций и инструментов, то гайдлайны фиксируют их в конкретной форме и правилах. Технически наш гайдлайн представляет собой фундамент из эволюционирующего набора правил, которые определяют порядок работы с интерфейсами.

Для организации UI-kit мы используем иерархию из популярного atomic design Бреда Фроста, разделяя компоненты по принципу возрастания их сложности на атомы, молекулы, организмы, шаблоны и страницы.

В состав атомарного уровня вошли основные вводные из визуального языка: цвет, форма, шрифт и сетка.

На молекулярном уровне оказались кросспродуктовые элементы, образующие скелет интерфейса любого нашего продукта: кнопки, ввод, области текста, всплывающие подсказки, выпадающие меню и другие.

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

В список шаблонов попали наработки для новостных проектов, в основном для медиа. Уровень конкретных страниц мы рассматриваем скорее как архив наработок.

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

Стек библиотеки сейчас — React + JSS. У React уже сформировалось большое активное сообщество (к тому же его лицензия недавно обновилась на MIT). JSS (CSS в JavaScript) отлично подходит нам в качестве техники для удобной генерации таблиц стилей в реальном времени с возможностью глубокой кастомизации. Мы выбрали такую пару из-за специфических требований к дистрибуции библиотеки — она должна была быть максимально простой.

Закрытая часть разработки ведется в GitLab, на GitHub попадает стабильная актуальная версия, которую можно выпустить вовне без страха за NDA. Обновление библиотеки происходит через обновление NPM-пакета раз в неделю, о крупных релизах заранее предупреждают все команды.

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

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

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

Не всегда всё шло гладко. На начальных этапах мы больше всего переживали за технические аспекты организации системы, совсем забыв о простом человеческом факторе.

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

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

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

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

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

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

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

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

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

Реализацию дизайн-системы в продуктах уже сейчас можно увидеть на «Рамблер/почте» и на новых медийных вертикалях «Рамблера». Компоненты обновляются на нашем GitHub, а основные принципы визуального языка описаны на сайте о бренде нового «Рамблера», который скоро обновится.

#дизайн