СберТаргет — рекламная платформа, в интерфейсе которой использовались компоненты как минимум трёх разных дизайн-систем. Я собрал общую библиотеку компонентов и описал правила их использования для дизайнеров и разработчиков. Система позволила постепенно обновлять существующие интерфейсы и стала основой для мобильной версии продукта.
За несколько лет СберТаргет переходил от команды к команде. Каждая приносила свои решения: поля ввода отличались формой, а кнопки в соседних разделах — цветом и типом, хотя выполняли одинаковые действия. Похожие формы, таблицы и фильтры были собраны на разных компонентах.
Общей библиотеки и правил выбора компонентов не было. Начиная новый макет, дизайнер не знал, какое решение считать актуальным, и часто создавал ещё один вариант. С ростом продукта это мешало работе: команды заново собирали интерфейсы для задач, уже решённых в других разделах.
Я начал с аудита: собрал существующие интерфейсы и сравнил повторяющиеся сценарии. Нужно было отделить различия, необходимые пользователям, от тех, которые остались после смены команд.
При обновлении продукта мы сохраняли рабочие сценарии, а существующие интерфейсы постепенно переводили на общие компоненты и паттерны. Такой подход позволял приводить разделы к общей системе без полной переделки привычных пользователям экранов.
Перед сборкой компонентов я сформировал общую основу: типографические и цветовые токены, сетку, правила отступов и адаптации к разным размерам экрана. Они задавали единые параметры оформления для компонентов из разных разделов продукта.
Токены организовал по модели «примитивы → семантика → компоненты»: от базовых значений к их назначению и использованию в конкретных элементах. Семантический слой разделил на пять категорий: фон, поверхности, границы, текст и иконки, действия.
На этой основе я собрал библиотеку ключевых компонентов. Описал их варианты, состояния, ограничения и правила поведения. Больше всего времени ушло на проработку ошибок, загрузки, недоступных действий, длинного контента и других пограничных случаев.
При этом общие компоненты ещё не обеспечивали одинакового поведения интерфейсов. Команды по-разному собирали из них формы, таблицы и фильтры для похожих задач.
Поэтому я описал повторяющиеся UX-паттерны: работу с формами и таблицами, фильтрацию, статусы, навигацию и пустые состояния. Они задавали правила сборки и поведения повторяющихся сценариев в разных разделах продукта.
Общие правила понадобились и для графики: в разделах использовались разные наборы иконок и стили изображений. Иконки я свёл к одному набору. Готовых иллюстраций для сценариев рекламного кабинета не было, а заказывать изображения под каждую задачу было долго. Я собрал тематические примеры, разобрал особенности их стиля и настроил генерацию.
Чтобы команда могла создавать новые иллюстрации в том же стиле, я сделал конструктор с готовыми настройками. Достаточно было описать нужное изображение для своего сценария — заново составлять подробный запрос к модели не требовалось. Для генерации использовал Nano Banana Pro через Magnific.
Изначально СберТаргет проектировали для компьютеров. Исследование показало, что значительная часть пользователей регулярно заходит с мобильных устройств. На небольшом экране плотные таблицы, сложная навигация и элементы управления были неудобны.
Для работы на разных устройствах библиотеку разделили на Web и Mobile. Общий визуальный стиль сохранили, а размеры элементов, навигацию, плотность интерфейса и способы взаимодействия адаптировали под устройство.
Развитие системы требовало общих правил принятия решений. На регулярных встречах по дизайн-системе я вместе с дизайнерами, разработчиками и продактами разбирал запросы команд: нужен ли новый компонент, можно ли использовать существующий паттерн и пригодится ли решение другим направлениям.
Иногда вместо добавления компонента требовалось пересмотреть сам пользовательский сценарий. Принятые решения фиксировали в системе и обсуждали с остальными командами, чтобы они могли использовать их в своих задачах.
У команд появилась общая библиотека и правила её развития: как выбирать компоненты, обсуждать новые запросы и согласовывать изменения.
