Дизайн-система, вычистившая 10 лет легаси

Проблема

10 лет без дизайнера, как это выглядело

Платформа состоит из шести сервисов, у каждого — своя административная панель для операторов.

Около 10 лет эти панели строились разными командами на Bootstrap без дизайнера и без UX-исследований. Функционал копился, но не пересматривался: операторы работали в интерфейсах, где часть элементов им непонятна или не нужна. В формах MDS они постоянно пропускали поля — не понимали их назначения и боялись ввести неверные данные.

Дизайнеры GS Group были заняты другими продуктами — DREAMPlatform все эти годы жила силами разработки.

Задача. Свести шесть сервисов к единому интерфейсу и упростить поддержку — так её поставили. Я переопределила её шире: вместе с унификацией вычистить мёртвый функционал, задать процесс, по которому в систему попадает только нужное, и собрать компоненты так, чтобы три команды разработки их использовали, а не обходили.

Мой вклад — три решения из многих, принятых за год работы

Решение 1. Легаси

Дизайн-система как чистка легаси, а не косметика

Контекст. Я несколько раз ездила в офис Триколора, сидела рядом с операторами, наблюдала, как они работают. И увидела, что проблема глубже: не в том, как выглядят кнопки, а в том, что значительная часть функционала мёртвая.

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

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

Осознанный компромисс. Полный редизайн UX-флоу 6 сервисов был нереалистичен за год с командой из 2 дизайнеров. Осознанно ограничились чисткой легаси и унификацией, без перепроектирования сценариев.

Решение 2. Процесс

Дизайн-система изменила культуру разработки

Контекст. Каждая команда жила сама по себе: оператор просит — разработка делает. Так копился хаос.

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

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

Решение 3. Архитектура

Осознанное упрощение ради внедрения

Контекст. Команды разработки с разным стеком, привыкли решать UI сами. Если компоненты сложные или негибкие, команды обойдут систему и продолжат делать по-своему.

Решение. Делала компоненты простыми в сборке и переиспользовании: минимум вложенностей, универсальные. Единая система цветов, типографики и отступов для всех сервисов. 40+ компонентов с документацией в Confluence — по каждому описала, где и как он используется. Применила систему пилотно на одном сервисе: выкатили, наблюдала за работой операторов с обновлённым сервисом, команды приняли — и только после этого масштабировали на остальные.

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

Роль Senior Product Designer: первый дизайнер, три команды, процесс

• Первый дизайнер на платформе: вся дизайн-система и спецификации для трёх команд разработки.
• Изучила интерфейсы шести сервисов до старта — выявила повторяющиеся компоненты и общие паттерны.
• Подключила второго дизайнера и распределила компонентную работу.
• Выстроила цикл с выделенными фронт-разработчиками: дизайн → вёрстка → ревью у меня → тест → раскатка.
• Защищала состав системы на регулярных демо лидам команд и бизнесу.

Результат и рефлексия

Шесть сервисов на одной системе, которая живёт без меня

Все 6 сервисов платформы работают на дизайн-системе. По обратной связи от руководителей Триколора, операторы перешли на единый интерфейс быстрее, чем ожидалось. Переключение между сервисами перестало быть проблемой.

Что я вынесла из проекта

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

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