Меня зовут Света, я дизайнер интерфейсов в DNS. В этой статье хочу рассказать про то, как мы за 6 месяцев прошли путь от интерфейсного хаоса до целостной дизайн‑системы, которая изменила не только продукт, но и процессы внутри команды.

Что такое Редакторская?

Если вы знакомы с сайтом или приложением DNS, вы могли видеть карточки товаров. Так вот, за фото, название товара, характеристики и другое наполнение отвечает CMS — DNS REDACTOR.

Один из сотрудников провёл красивую аналогию:

Редакторская — это как двигатель в автомобиле, он спрятан под капотом и без него машина не поедет.

Творческий произвол и его последствия

Когда меня знакомили с продуктом, первым делом показали одну из главных страниц. То, что я увидела, можно было писать одним словом: Франкенштейн. Нагромождение селектов, инпутов, таблиц и кнопок, каждый из которых выглядел и вёл себя по‑своему. На одной странице можно было насчитать 6 типов кнопок.

Почему так получилось? Ответ очевиден: не было чётких гайдов, единых компонентов и прописанных паттернов. Дизайнеры каждый раз рисовали страницы с нуля, а так как над разными страницами работали разные дизайнеры, они могли отличаться не только внешне, но и функционально. Например, где‑то кнопка сохранения была у заголовка, а где‑то внизу страницы.

Разработчики, если макетов не было, верстали так, как считали нужным, из страницы к странице заново создавая элементы.

Какие можно выделить проблемы для разных представителей команды:

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

• Дизайнер. Вы не понимаете какие цвета и компоненты использовать в работе, каждый экран собираться с 0. Из‑за этого время работы над задачей увеличивается.

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

Все эти проблемы может решить дизайн‑система.

Цвет — основа всего

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

Что получилось в итоге:

Семантика цветов

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

Благодаря отображению переменных разработчик просто копирует данные в CSS.

Зависимость от базовой палитры

Если через год захотим сменить основной цвет с синего на фиолетовый — просто поменяем значение в родительской палитре, а семантические цвета обновятся автоматически.

По факту мы каждому семантическому цвету присваем родительский со степенью прозрачности:

‑color‑surface‑generic‑dark: rgba(‑color‑core‑black, 0.68)

Альфа‑канал

Добавили цвета с прозрачностью (RGBA) — это нивелировало проблему 50 оттенков серого.

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

Так же мы перешли на токены, поэтому переключение между светлой и тёмной темой теперь занимает пару кликов.

Исчез соблазн поставить между блоками 5 или 7 пикселей, потому что спейсинги как и цвет с радиусом были занесены в переменные.

Компоненты: битва с диким селектом и рождение гайдов

В процессе работы я спросила у разработчиков: «Какой компонент для вас самый запарный?». И практически все сказали: «Select».

Для меня он тоже оказался самым сложным. Я переделывала его 4 раза.

Именно благодаря этому компоненту в нашей ДС начали появляться гайды использования, потому что в процессе работы возникали всё новые и новые кейсы, которые надо было описать.

Я настолько задушнила саму себя, что в какой‑то момент меня начало тошнить от селекта. Казалось, вот теперь я учла все моменты, но потом в голове звучало: «А что если вариантов не найдено? А если пользователь выберет все 100 пунктов?». Пришлось собирать силы в кулак и описывать всё новые и новые сценарии.

Зато наличие таких гайдов практически избавило разработчиков от вопросов на этапе проектирования. Конечно, какие‑то кейсы я упускала, и здорово, что ребята их подсвечивали.

Здесь вы можете увидеть как ведёт себя дикий селект в естественной среде обитания.

Особенно интересно посмотреть, как скачет поле при выборе всех вариантов.

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

Теперь мы просто показываем тег «Все», а те пункты, которые пользователю не нужны, он удобно уберёт в списке.

Любимый компонент: Aside-header

Моим любимым компонентом и одновременно нововведением стал Aside‑header. Вы могли видеть подобное в CRM‑системах. До этого в редакторской была обычная, среднестатистическая шапка.

Его преимущества:

1. Не занимает пространство сверху. Для Редакторской, в которой основой интерфейса служат таблицы, лишний сохраненный пиксель — возможность уместить еще больше табличных строк.

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

3. Возможность для развития и добавления нового функционала.

Долой страшные таблицы

На Редакторской одна из проблем — фильтры. Они есть и их много. А что если их не убрать в шапку? Похожие кейсы были у Контура, и мы тоже решили внедрить такую фичу.

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

Работа над дизайн-системой

Я немного погрузила вас в компоненты, а теперь расскажу, как же мы организовывали работу над ними.

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

В процесс тестирования добавился еще один пункт — «визуальное тестирование». В какой‑то момент мы столкнулись с проблемой, что в прод уходят компоненты, которые не до конца соответствуют макетам. А кто как не дизайнер, может своим пристальным взглядом определить, что в календаре не те спейсинги?

Новая культура макетов

Дизайн‑система решила не только компонентный вопрос, но и процесс создания макетов. Это было вызвано тем, что беспорядок затронул не только компоненты. Если ты, как дизайнер, который не работал над задачей, заходил в макет, то не мог ничего понять. Ни одного прорисованного сценария, ни одной заметочки... И все это в купе с отсутствием нейминга слоёв и хоть каких‑то подписей.

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

Вот некоторые тезисы:

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

2. Сценарий начинается с его триггера и заканчивается завершением действия.

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

4. Заметки помогут продакту составить заявку, а разработчику обратить внимание на важные моменты, если продакт о них забыл.

Мы хотели дизайн систему, а получили...

Мы хотели дизайн‑систему, а получили комплексное преобразование продукта и рабочих процессов, которое вышло далеко за рамки простого набора компонентов.

Мы получили:

1. Единый визуальный язык с продуманной семантикой цветов, фиксированными спейсингами и радиусами, с установленными паттернами, которым подчинены элементы на странице.

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

3. Новую культуру проектирования с обязательными сценариями, подписями и заметками, которая синхронизирует всех членов продуктовой команды.

4. Не просто библиотеку UI, а целостную систему, которая экономит время, а значит и деньги компании на каждом этапе разработки.

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

Внутренние продукты — это лицо компании внутри неё. Они тоже могут помогать в работе, как и удобное кресло.

P. S. Приглашаю всех в свой телеграм‑канал д(а)изайн, в котором душню на темы дизайна и делюсь work life.