Дизайн-система Vidau Systems

Подробнее о процессе

Почему инженерным продуктам нужна была общая система

Vidau Systems ведёт несколько параллельных продуктов для одной отрасли: VS Subtitles, VS Ecosystem, Traffic, Control, IGW и ряд внутренних направлений, которые появлялись как эксперименты и стартапы. Пользователи разные: редакторы субтитров, операторы эфира, инженеры, администраторы. Общее одно: человек работает с продуктом целую смену за десктопом, часто в аппаратной, часто под временным давлением.

Бизнес рассчитывал на два эффекта от консистентности. Утилитарный: инженер, который знает один продукт Vidau, быстрее осваивает соседний. Репутационный: по интерфейсу видно, что это продукт одной компании.

Стартовая точка была не нулевой. UI-kit существовал в зачаточном виде: кнопки, инпуты, чекбоксы, радиокнопки. Продуктовые макеты тоже уже были.

Правила существовали только в голове лида

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

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

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

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

Моя роль и границы

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

Определял лид: цветовую палитру, типографику, систему отступов, общую структуру библиотеки, направление развития.

Делала я:

• аудит существующих компонентов и приведение их к системному виду;
• проектирование вариаций и полного набора состояний;
• формулирование правил использования;
• ведение документации в Яндекс Вики.

Делали вместе: правила выбора носителя уведомления, разбор спорных сценариев, решение о том, какие компоненты попадают в общую систему.

Дизайн-система не была моей основной задачей. Основное время занимали продуктовые задачи, системой я занималась всё свободное от продукта время, на протяжении двух лет.

Ключевые решения

1. Единый шаблон документации как способ вынести правила из головы лида

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

Что я сделала. Зафиксировала единую схему, по которой описан каждый компонент библиотеки:

1. Описание. Что это за элемент и как он себя ведёт.
2. Где используется. Сценарии применения, часто с явным указанием, где применять запрещено.
3. Компонент. Базовый вид.
4. Вариации. Матрица «состояние × размер» с примером для каждой ячейки.
5. Примеры использования. Компонент внутри реальных экранов продуктов.

Почему это работает. Схема делает библиотеку предсказуемой: любой компонент описан по одной и той же структуре, и её не нужно объяснять каждый раз заново. Незнакомый компонент читается за минуту, потому что читатель заранее знает, где искать нужное. Раздел «Где используется» с запретами закрывает самый частый спор в дизайн-системе: можно ли применить компонент там, где он технически влезает. Пример такого правила прямо в библиотеке: «НЕ используем в Control».

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

Trade-off. Шаблон требует дисциплины и времени: каждый компонент нужно не только нарисовать, но и обвязать текстом и примерами. При параллельной работе с продуктовыми задачами это тормозило скорость наполнения библиотеки. Обмен я считаю оправданным: недокументированный компонент возвращает команду к ручным объяснениям.

2. Как система доезжала до продуктов

Это самая затратная часть работы, и она объясняет половину ограничений проекта.

Схема. Общий файл дизайн-системы плюс собственная копия библиотеки внутри каждого продукта. Автоматической связи между ними не было: бесплатный план Figma не даёт публикации командной библиотеки.

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

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

3. Критерий попадания компонента в систему

Проблема. Запросы «нужен компонент, которого нет» приходят постоянно. Если добавлять всё, библиотека распухает и теряет управляемость. Если не добавлять ничего, продукты начинают жить своими локальными наборами.

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

Правило простое, при этом именно оно определяет, останется ли дизайн-система рабочим инструментом или превратится в свалку.

4. Отказ от wireframes как этапа

Решение про мой собственный процесс. Оно показывает, что система дошла до рабочего состояния.

Что произошло. На проекте панели управления я прошла полный цикл: схематичный user flow, затем wireframes, затем финальные экраны. Уже в процессе стало видно, что отдельный этап wireframes почти ничего не добавил. Библиотека была достаточно зрелой, чтобы структуру экрана можно было сразу собирать из готовых компонентов, и промежуточный схематичный слой дублировал работу.

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

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

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

Как устроена система

Около 30 задокументированных компонентов, собранных в тёмной теме, что соответствует условиям работы операторов в аппаратных и студиях.

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

Действия. Кнопки, ссылка, toolbar, выпадающее меню и попап.

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

Обратная связь. Alert global, Alert local, Toast, Notification, тултип, хинт, прогресс-бар, скелетон страницы.

Прочее. Модальные окна двух ширин (496 и 960 px), аватары и сущности.

Размерная шкала. Единая для всех интерактивных элементов: S = 32 px, M = 40 px, L = 48 px. Контролы выбора зафиксированы на 24 px. Одна шкала на кнопки, поля, селекты, вкладки, пагинатор и меню убирает вопрос о высоте элемента из ежедневной работы.

Состояния. Для каждого интерактивного компонента описаны default, hover, focus, selected, selected hover, error, disabled. Состояния разложены матрицей для каждого компонента.

Брейкпоинты. Горизонтальное меню задокументировано в трёх ширинах: 960, 1600 и 1920 px. Значения пришли из реальных компоновок продуктов Vidau. Информационно насыщенные таблицы требуют полной ширины. Интерфейсы с боковой панелью устройств живут иначе. Менее плотные таблицы нет смысла растягивать на весь широкий монитор, их ограничивают по ширине и центруют. Брейкпоинт здесь описывает тип компоновки.

Работа с командой и сопротивление

Верхнее меню: решение, с которым я была не согласна

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

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

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

Traffic: цена консистентности

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

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

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

Ограничения

• Право решения. Ключевые решения принимал дизайн-лид.
• Инструменты. Бесплатная Figma без Variables и без публикации библиотеки, синхронизация вручную через лида.
• Версионирование. Две глобальные версии системы, детальной истории изменений по компонентам не велось. Вопрос поднимала и разработка.
• Параллельная загрузка. Система развивалась во время, свободное от продуктовых задач.

Результат

Охват. Одна библиотека стала общей основой для продуктовой линейки компании: VS Subtitles, VS Ecosystem, Traffic, Control, IGW и несколько внутренних направлений. Разные команды с разными задачами приняли её в работу. Это результат команды дизайн-системы целиком.

Глубина. Библиотека выросла с нескольких базовых элементов до примерно 30 компонентов, каждый с вариациями, полным набором состояний, правилами использования и примерами внутри реальных экранов.

Правила перестали зависеть от одного человека. До появления полноценной системы правки по консистентности приходили на макеты регулярно. Когда правила закрепились в компонентах и документации, такие правки практически исчезли.

Скорость проектирования. Сборка новых интерфейсов заметно ускорилась. Наиболее наглядное подтверждение: на Лицензии этап wireframes стал не нужен, экран сразу собирался из компонентов системы.

Рефлексия

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

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

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

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