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

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

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

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

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

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

Обзорная карта продуктов Vidau с отметкой, какие подключены к системе

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

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

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

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

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

Три варианта одного элемента из трёх продуктов до систематизации — наглядное доказательство разнобоя

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

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

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

Делала я:

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

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

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

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

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

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

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

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

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

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

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

Одна страница библиотеки целиком, с подписанными зонами шаблона

2. Токены текстом, когда нет инструмента

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

Риск. Без токенов разработчик подбирает цвет на глаз или выдёргивает hex из макета. Через полгода в коде живёт двадцать оттенков серого.

Решение. Имена токенов проставлены текстом рядом с каждым вариантом компонента: interface/32, accent/500, gray/900, text-interface/CC. Для разработки дополнительно вручную дописаны параметры компонентов и значения цветов в формате CSS.

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

Фрагмент матрицы вариаций с подписанными токенами рядом с ячейками

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

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

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

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

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

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

Схема «общий файл и копии в продуктах» со стрелками ручной синхронизации

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

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

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

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

4. Правила вместо разового обсуждения: Toast, Alert, Notification

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

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

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

Что здесь было не моим решением. Продуктовая логика статусов пришла из Control: разделение на события системы и события устройства, набор ролей (info, normal, maintenance, warning, error, offline, default) определялся логикой оборудования. Продукт проектировал другой дизайнер. Моя часть лежала в общем правиле выбора носителя и в оформлении этого блока в библиотеке.

Матрица статусов Alert / Toast / Notification из библиотеки

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

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

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

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

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

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

Сравнение двух процессов: полный цикл на панели управления и сокращённый на Licenses

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

Около 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-дизайнер. У лида было устойчивое видение, финальное решение осталось за ним. Я приняла его и продолжила работу.

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

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

Альтернативные прототипы верхнего меню рядом с принятым вариантом

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

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

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

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

Ограничения

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

Результат

Количественных метрик по дизайн-системе в компании не собирали. Ниже то, что подтверждается артефактами и фактами работы.

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

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

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

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

Что из этого моё

• около половины компонентов библиотеки, вторую половину вёл второй дизайнер;
• единый шаблон документации, применённый ко всей библиотеке, включая компоненты, которые делала не я;
• правила использования и запреты в описаниях компонентов;
• документация в Яндекс Вики;
• спецификации и значения в CSS для разработки;
• отказ от этапа wireframes в собственном процессе после проверки на двух проектах.

Рефлексия

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

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

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

Что сделала бы иначе, если бы определяла направление сама

1. Платная подписка с публикацией библиотеки, чтобы убрать ручной перенос компонентов между файлами.
2. Версионирование с самого начала: релизы компонентов, changelog, понятный процесс обновления для дизайна и разработки.
3. Связка дизайна и кода: единый источник токенов, живая библиотека на стороне фронтенда, регулярная сверка.
4. Обратная связь у дизайнеров и разработчиков как основа приоритетов развития библиотеки.
5. Обновление визуального языка — часть решений сейчас выглядит устаревшей.

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