Сработало
Порядок токены → атомы → паттерны. Единый шаблон описания для каждого компонента. Поэтапное внедрение по уровню риска. Демо со всей командой.

Переход НОТА.Визор от ручной отрисовки каждого экрана к масштабируемому производству интерфейсов: единый набор токенов, компонентов и правил и передача, с которой фронтенд и QA работают напрямую.
Контекст
НОТА.Визор — платформа онлайн-взаимодействия с ФНС в режиме налогового мониторинга: витрина данных, отчётность, внутренний контроль и интеграция с «Налог-3». Полная предыстория — в кейсе о самом продукте.
Роль
Дизайн-систему я инициировал, спроектировал с нуля и довёл до внедрения — параллельно с текущей продуктовой работой, без выделенного времени и без второго дизайнера.
Порядок работ: токены и стили → проектирование компонентов → рефакторинг старых экранов → внедрение.
Сложности
Фронтенд-команда собрала библиотеку компонентов непосредственно по дизайн-системе: ни Ant Design, ни Vue UI-кита в основе. Каждая спецификация должна была быть точной настолько, чтобы служить источником истины для разработки.
Таблица собрала на себе больше требований, чем любой другой компонент: плотность строк, выравнивание колонок, сортировка, состояния строки и ячейки, инлайн-редактирование. Всё это пришлось развести по отдельным свойствам атомов — чтобы нужный вид таблицы собирался переключателями, а не рисовался заново под каждый экран.
Требования уточнялись по мере прояснения контекста компонента. Финальная спецификация потребовала нескольких итераций и затем стала опорой и для дизайна, и для фронтенда.

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

Грамматика задаёт правило применения. text-primary — заголовки и основной текст,
text-tertiary — плейсхолдеры и подсказки, text-danger — ошибки, неуспешная валидация
и разрушающие действия. Выяснять, какой из серых здесь третий, не требуется.

Библиотека
Ядро набора: Button, Input, Select и Multiselect, Table, Modal, Alert, Pagination, Tabs. Поверх них — паттерны, постоянно востребованные таблицами и формами: пустые состояния, инлайн-редактирование, валидация.

Документация написана так, чтобы фронтенд и QA собирали компонент по ней, не возвращаясь к дизайнеру: назначение, свойства, все состояния и разобранные примеры правильно / неправильно.
Процесс
Каждый слой проверялся на реальных экранах продукта, прежде чем переходить к следующему. При переносе компонентов в рабочие макеты проявлялись пробелы: недостаточный контраст, отступы, ломающиеся в контексте, краевые случаи, не предусмотренные абстрактной спецификацией. Это возвращало работу на уровень токенов и оттуда снова вперёд по стеку компонентов.
Фронтенд-команда проверяла каждый слой до выхода в прод, поэтому к моменту сборки сложных компонентов фундамент был устойчивым.
Внедрение шло поэтапно, по уровню риска: сначала стили → кнопки → поля ввода, затем таблицы, фильтры и формы. Концепцию утвердил владелец продукта, текущие изменения разбирались с фронтенд-командой на демо и дизайн-ревью.
Результаты
Оценочные цифры, основанные на производственном опыте команды за время внедрения, — не контролируемое измерение.
−40%
Скорость дизайна
−70%
Качество интерфейса
3–4 → 1–2
Коммуникация
<5%
Стандартизация
Ретроспектива
Порядок токены → атомы → паттерны. Единый шаблон описания для каждого компонента. Поэтапное внедрение по уровню риска. Демо со всей командой.
Больше времени на связи между атомами и молекулами и более раннее подключение сложных паттернов: сценарии таблиц и правая панель навигации проявились поздно и стоили лишних итераций.