Финансовый дашборд
Design System & Product Design
Повторять знакомое поведение
Общие компоненты должны поддерживать сценарии разных внутренних продуктов.
00:00
Mar 29, 2026
Объединила компоненты, адаптивные правила и поддержку изменений
Локальная дизайн-система для внутренних продуктов и сайтов холдинга. Моя роль — дизайнер и менеджер: от аудита базы до документации и взаимодействия с разработкой.
Category:
Design System
/* Problem */
С какой задачи началась работа
Я работала над общей дизайн-системой для редизайна сайта и личного кабинета с фильтрами и показателями. Начала с изучения компонентной базы и требований к интерфейсам.
Для меня было важно не только собрать библиотеку, но и описать адаптивность, применение компонентов и поддержку изменений в дизайне и коде.
/* Task framing */
Как разложила задачу по участникам и целям
Я связала требования продуктов с задачами дизайнеров, разработчиков и менеджмента: знакомое поведение интерфейса, повторное использование компонентов и понятные правила изменений.
Собирать последовательно
Использовать библиотеку и адаптивные правила вместо локальных решений на каждом экране.
Понимать контракт
Документация описывает применение и изменения элементов.
Поддерживать внедрение
Прямая коммуникация с клиентом и регулярные встречи с разработчиками.
/* Process */
Как была организована работа
Совмещала дизайн и управление проектом: изучала компонентную базу, прорабатывала адаптивные правила, готовила документацию и обсуждала интеграцию с разработчиками.
Аудит базы
Изучала существующие компоненты и требования продукта.
Адаптивная система
Прорабатывала компоненты для трёх диапазонов ширины и их поведение внутри каждого.
Документация
Описывала правила использования компонентов и поддерживала историю изменений.
Сопровождение
Обсуждала интеграцию с разработчиками и сопровождала изменения в дизайне и коде.
/* Evidence */
Система учитывает размеры экрана и жизненный цикл компонента
Я проработала адаптивные правила для трёх диапазонов: 320–767, 768–1023 и 1024–1440 px. Вместе с компонентами описала их применение и изменения, чтобы библиотекой можно было пользоваться и поддерживать её в работе.
Адаптивные правила
Компоненты адаптируются внутри диапазонов, а не только в трёх фиксированных размерах.
Изменения в дизайне и коде
История помогает видеть, что изменилось в компонентах и где требуется обновление.
/* Decision map */
Компонент — это поведение, а не только внешний вид
Я рассматривала компонент как набор правил: где его использовать, как он адаптируется и как сообщать об изменениях. Эти принципы связывали библиотеку с задачами продукта и разработки.
01 · Фокус
Повторяемость
Решение
Общий набор компонентов
Как проверить
Проверить соответствие одинаковых элементов между продуктами.
02 · Фокус
Адаптивность
Решение
Правила внутри трёх диапазонов ширины
Как проверить
Проверять промежуточные ширины и длинный контент, не только три статичных макета.
03 · Фокус
Изменения
Решение
Документация и Changelog
Как проверить
Дать команде понять, что изменилось и где требуется обновление.
/* Flow */
От запроса на компонент до поддержки его изменений
Для меня работа над системой не заканчивается передачей макета. Ниже — общая логика: сверить потребность, описать компонент, обсудить реализацию и поддержать изменения.
- 01
Сверить потребность
Проверить существующую базу и сценарий.
- 02
Спроектировать
Определить варианты и адаптивность.
- 03
Передать
Описать компонент и обсудить реализацию.
- 04
Поддержать
Проверить внедрение и записать изменение.
Новый вариантСверить, действительно ли он отличается по поведению.
Длинный контентПроверить устойчивость компонента на разных ширинах.
ОбновлениеУточнить влияние на существующие экраны и сообщить команде.
/* Artifact 01 */
Библиотека в работе
При проектировании сайта я работала с вариантами полей, кнопок и меню из общей библиотеки.
/* Artifact 02 */
История изменений
В сопровождении системы я использовала Changelog, чтобы изменения компонентов в дизайне и коде оставались понятными команде.
/* Artifact 03 */
Как система помогла ускорить работу
По итогам проекта зафиксировали сокращение среднего времени задач разработки на 30%, дизайна — на 40%. Эти оценки относятся к этому проекту; я не рассматриваю их как универсальный эффект для любой команды.
/* Outcome */
Что было готово по итогам работы
Я работала над локальной компонентной библиотекой, адаптивными правилами и документацией. Вместе с разработчиками обсуждала интеграцию и поддерживала изменения, чтобы система оставалась рабочим инструментом команды.
Компонентная база
Единая основа для продуктов и сайтов.
Адаптивные правила
Три диапазона и поведение внутри них.
Поддержка изменений
Документация, Changelog и работа с разработчиками.
/* Measurement plan */
Как оценивать результат дальше
Для дальнейшей оценки я бы дополнила скорость работы показателями переиспользования компонентов и стоимости обновлений. Ниже — направления проверки, а не дополнительные результаты проекта.
Время принятой задачи
Медиана времени от согласованного начала до приёмки, отдельно для дизайна и разработки. Источник — трекер; сравнивать сопоставимые типы задач.
Переиспользование
Элементы, собранные из согласованной библиотеки / элементы, для которых есть подходящий компонент. Источник — аудит макетов и реализации.
Цена обновления
Регрессии и трудозатраты миграции после изменения компонента. Ускорение не считать успехом, если растёт число дефектов или исключений.
/* Reflection */
Что я вынесла из проекта
Для меня дизайн-система — не только библиотека компонентов. Её ценность зависит от того, насколько команде понятны правила применения, как согласуются изменения и насколько удобно поддерживать интерфейсы после передачи в разработку.
