Что сработало
Последовательность токены → базовые компоненты → сложные паттерны, единый шаблон документации, постепенное внедрение и регулярные демо со всей командой.
Рефакторинг дизайн-системы
Как я заменил ручную отрисовку экранов единой системой токенов, компонентов и правил. Фронтенд-разработчики и QA использовали спецификации напрямую, без дополнительных пояснений по каждому состоянию.
- Роль
- Единственный продуктовый дизайнер
- Период
- Январь — июль 2023
- Библиотека
- 40+ компонентов
- Покрытие
- 100% экранов
Контекст
Продукт на 500+ экранов
НОТА.Визор — платформа для налогового мониторинга. Через неё крупные компании передают данные и отчётность в ФНС, проводят внутренний контроль и работают с АИС «Налог-3». Подробнее о продукте — в предыдущем кейсе.
Роль
Инициировал и провёл рефакторинг
Я сам предложил создать дизайн-систему, спроектировал её с нуля и довёл до внедрения. Всё это шло параллельно с текущими задачами продукта, без выделенного времени и второго дизайнера.
Работу разделил на четыре этапа: токены и стили → базовые компоненты → рефакторинг старых экранов → внедрение в продукт.
Сложности
Три самые трудоёмкие задачи
- Собственная библиотека без готового UI-фреймворка
В основе продукта не было Ant Design или готового Vue UI-кита. Фронтенд-команда собирала компоненты по моим спецификациям, поэтому в документации нужно было точно описать поведение, состояния и краевые случаи.
- Таблицы оказались самым сложным компонентом
Таблица должна была поддерживать разную плотность строк, выравнивание колонок, сортировку, состояния строк и ячеек, а также редактирование внутри таблицы. Я разделил эту логику на свойства компонентов, чтобы нужный вариант можно было собрать настройками, а не рисовать заново для каждого экрана.
- Панели навигации потребовали нескольких итераций
Поведение левой и правой панелей зависело от контекста экрана. Часть требований стала понятна только после проверки на реальных сценариях. Я несколько раз уточнял спецификацию, пока она не начала одинаково работать для дизайна и фронтенд-разработки.
Стандарты
Названия токенов объясняют их назначение
Каждое имя токена собиралось по одной схеме из четырёх возможных частей. Простые названия оставались короткими, а состояние и уровень иерархии добавлялись только тогда, когда были нужны.
Вместо условного «третьего серого» команда использовала понятные названия:
text-primary — для основного текста и заголовков, text-tertiary — для подсказок и плейсхолдеров,
text-danger — для ошибок и разрушающих действий.
Библиотека
40+ компонентов и единый формат документации
В базовый набор вошли Button, Input, Select, Multiselect, Table, Modal, Alert, Pagination и Tabs. Для таблиц и форм я также описал повторяющиеся паттерны: пустые состояния, редактирование, валидацию и сообщения об ошибках.
У каждого компонента были назначение, свойства, все состояния, краевые случаи и примеры правильного и неправильного использования. Благодаря этому фронтенд-разработчики и QA могли работать со спецификацией без постоянных уточнений у дизайнера.
Процесс
Проверял систему на реальных экранах
Я не проектировал библиотеку отдельно от продукта. Каждый новый слой сразу проверял на рабочих экранах. Так находились проблемы, которые не были заметны в изолированном компоненте: недостаточный контраст, неустойчивые отступы и пропущенные краевые случаи.
Если проблема была системной, я возвращался к токенам или базовым компонентам, исправлял её и снова проверял на сложных сценариях. Фронтенд-команда подключалась на каждом этапе, поэтому ошибки не накапливались до конца работы.
Внедрение шло от наименее рискованных частей к наиболее сложным: сначала стили, кнопки и поля ввода, затем таблицы, фильтры и формы. Концепцию согласовал владелец продукта, а текущие изменения мы разбирали на демо и дизайн-ревью.
Результаты
Как изменился процесс работы
Оценочные цифры, основанные на производственном опыте команды за время внедрения, — не контролируемое измерение.
-40%
Время на проектирование экранаЯ использовал готовые компоненты и настройки вместо ручной отрисовки.
Скорость дизайна
-70%
Количество UI-дефектов на релизЕдиные состояния компонентов снизили количество случайных расхождений.
Качество интерфейса
3–4 → 1–2
Количество итераций дизайн-ревьюУ дизайна, продукта и разработки появился общий набор правил.
Коммуникация
<5%
Нестандартных компонентов в новых задачах.Новые элементы создавались только для экспериментальных или действительно уникальных сценариев.
Стандартизация
Показатели основаны на производственном опыте команды во время внедрения. Это оценка, а не результат контролируемого исследования.
Ретроспектива
Что оставил бы и что изменил
Что я сделал бы иначе
Раньше подключил бы сложные паттерны — прежде всего таблицы и правую панель. Их поведение в реальных сценариях проявилось поздно и потребовало дополнительных итераций.