DA.INDSD > 2. Дизайн > 2.5. Реклама > Разработка единой дизайн-системы — опыт «Рамблера»

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

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

Новый «Рамблер»

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

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

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

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

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

Архитектура дизайн-системы

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

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

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

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

  • Гибкость.
  • Сохранение интересов продукта.
  • Потенциал для эволюции.

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

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

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

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

  • Документация — описание бренда и его ценностей, визуальный язык, его принципы.
  • Исходники — сами файлы UI-кита и гайдлайны с правилами создания компонентов.
  • Компоненты — библиотека готовых фронтенд-компонентов, документация к ним, песочница.

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

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

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

Бренд

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

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

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

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

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

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

Гайдлайны

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

UI-kit

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

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

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

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

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

Библиотека компонентов

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

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

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

Команда

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

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

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

Культура дизайна в большой компании

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

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

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

Проектирование и прототипы

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

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

Процессы

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

Планы на будущее

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

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

Related posts

Comment