Дизайн-система Mindbox
Как я развивал дизайн-систему Mindbox на реальных продуктовых задачах: обновлял существующие компоненты, добавлял недостающие паттерны и описывал правила их использования.
Продукт
Платформа автоматизации маркетинга Mindbox
Этап
Формирование дизайн-системы
Фокус кейса
Некоторые изменения, которые я внёс в дизайн-систему
Моя роль
Product Designer – развивал компоненты, состояния и правила использования, проверял решения в продуктовых сценариях и готовил документацию.
Команда
Product Designer
Результат
Обновил существующие компоненты
Пересмотрел базовые контролы и привёл их к новому визуальному языку и актуальным сценариям продукта.
Добавил недостающие паттерны
Закрыл повторяющиеся задачи, для которых раньше не было общего системного решения.
Описал состояния и правила использования
Проработал основные, пограничные и ошибочные сценарии, чтобы компоненты одинаково применялись в разных разделах.
Контекст
Дизайн-система Mindbox развивалась параллельно с редизайном продукта. Часть компонентов уже существовала, но не соответствовала новому визуальному языку или не покрывала актуальные сценарии. Других паттернов в системе ещё не было.
Работая над продуктовыми задачами, я обновлял существующие компоненты и добавлял новые решения, которые можно было использовать в разных разделах. В этом кейсе собрана часть таких изменений, а не вся работа над дизайн-системой.
Для каждого решения нужно было закрыть конкретный сценарий, продумать состояния и проверить, что компонент не зависит от одного экрана.
Почему проект был важен
Без общих правил одинаковые элементы могли выглядеть и работать по-разному. Это усложняло проектирование, разработку и дальнейшее развитие интерфейса.
Дизайн-система должна была дать команде единый язык и сократить количество решений, которые приходится принимать заново.
Мой вклад
- Анализировал существующие компоненты и сценарии, которые они не покрывали.
- Обновлял базовые контролы под новый визуальный язык и продуктовые требования.
- Проектировал недостающие паттерны на основе реальных задач.
- Определял варианты, размеры, состояния и поведение.
- Проверял решения в макетах конструктора и других разделов.
- Описывал назначение компонентов и правила использования.
В кейсе показаны изменения в пяти областях: действия · ввод данных · работа с изображениями и файлами · навигация · обратная связь
Подробнее про компоненты
1. Обновил кнопку и группу кнопок
Проблема. За несколько лет использования реализация на фронтенде и компоненты в дизайн-системе разошлись: в продукте появились новые состояния и кастомные варианты, которые нигде не были описаны. Нужно было собрать реальные сценарии и восстановить единую иерархию действий.
Решение
Я проверил все места использования кнопок в продукте, нашёл кастомные реализации и учёл их в обновлённых компонентах. Параллельно пересобрал свойства в Figma, чтобы состояния и варианты настраивались предсказуемо, без ручных правок.
Для кнопок я определил типы по приоритету: Primary, Secondary, Tertiary и Negative, размеры S, M и L, варианты с иконками и основные состояния. Отдельно описал правила названий и количество Primary-действий на экране.
Для групп кнопок зафиксировал порядок: основное действие располагается слева, дополнительные – справа. Ограничил количество кнопок, определил размеры S и M и поведение группы при прокрутке в pop-up, popover, drawer и других контейнерах.
Ценность: иерархия и порядок действий остаются последовательными в разных сценариях продукта.
2. Обновил Input
Проблема. За несколько лет использования реализация Input на фронтенде разошлась с компонентом в дизайн-системе: появились новые состояния и кастомные варианты полей, которые нигде не были описаны. Нужно было собрать реальные сценарии и пересобрать Input так, чтобы он покрывал их одним компонентом.
Решение
Я проверил все места использования Input в продукте, разобрал кастомные реализации и перенёс необходимые сценарии в обновлённый компонент. В Figma упорядочил варианты и свойства, чтобы сложные конфигурации собирались через настройки компонента, а не ручными изменениями.
Я предусмотрел label сверху, слева и вариант без label, prefix и suffix, иконки, inline-select, дополнительное действие и текст ошибки. Также описал правила ширины и расстояния до связанных контролов.
Suffix можно изменять прямо в интерфейсе – например, подставлять px, % или другие единицы измерения, поэтому один компонент подходит для разных числовых параметров.
Также я добавил изменение значения перетягиванием иконки в prefix: визуальные параметры в конструкторе можно быстро подбирать прямо на экране, не вводя каждое новое значение вручную.
Ценность: один компонент поддерживает простые поля и сложные составные сценарии ввода.
3. Создал хлебные крошки
Проблема. В продукте появились сценарии с глубокой иерархией, но единого паттерна навигации между уровнями не было. Пользователю было сложно понять, где он находится, и быстро вернуться к родительскому разделу.
Решение
Я описал использование компонента для структур от трёх уровней, состояние текущего уровня и сворачивание части пути в троеточие. Если крошки не помещаются, они сокращаются, а не переносятся на вторую строку.
Ценность: навигация одинаково работает на полноразмерных страницах и в drawer.
4. Создал уведомления
Проблема. Обратная связь после действий была непоследовательной: разные сценарии по-разному сообщали об успехе, предупреждениях и ошибках, а несколько сообщений могли одновременно перегружать интерфейс.
Решение
Я проработал Success, Warning и Error, структуру заголовка, описания и ссылок, появление и закрытие уведомлений. Несколько сообщений объединяются в стек, чтобы не перекрывать интерфейс.
Ценность: результат действия заметен, а несколько уведомлений остаются управляемыми.
5. Создал компонент загрузки файлов
Проблема. В продукте не было единого компонента загрузки файлов, который покрывал бы весь сценарий: выбор и drag-and-drop, прогресс, ограничения, ошибки и отмену. В разных местах эти состояния приходилось решать отдельно.
Решение
Компонент поддерживает кнопку и drag-and-drop. Я проработал Hover и Dragover, ограничения формата и размера, сетевые и системные ошибки, процесс загрузки, отмену, а также варианты файла с превью и без него.
Ценность: одна модель поведения подходит для разных типов файлов и заранее объясняет пользователю ограничения.
6. Создал компонент «Изображение»
Проблема. Единообразно отображать изображения и понятно показывать состояния, когда картинка отсутствует или повреждена.
Решение
Я создал компонент с тремя состояниями: Empty, Empty with text и Damaged. Для пустого состояния предусмотрел два варианта — только с иконкой или с дополнительным пояснением. Для повреждённого изображения сделал отдельную иконку и текстовое сообщение.
Ценность: по состоянию компонента сразу видно, изображение отсутствует или повреждено.
7. Обновил color picker
Проблема. Старый color picker визуально устарел и содержал лишние элементы, которые усложняли выбор цвета.
Решение
Я добавил скругления, обновил маркер выбранного цвета, увеличил рабочие области и ячейки недавних цветов. Убрал отдельные поля RGB, а прозрачный цвет закрепил первым среди недавно использованных.
Ценность: контрол стал компактнее, понятнее и соответствует новому визуальному языку Mindbox.
Результаты подробнее
🥇 Подборка изменений
В кейсе показана часть моей работы над дизайн-системой: обновление существующих контролов и создание недостающих паттернов для продуктовых задач.
🥇 Состояния и поведение
Для компонентов описаны основные, пограничные и ошибочные состояния. Это помогает одинаково решать повторяющиеся сценарии в разных разделах продукта.
🥇 Повторное использование
Решения создавались на конкретных задачах, но проверялись за пределами одного экрана. Благодаря этому их можно использовать в следующих разделах Mindbox.
🥇 Что изменилось для продукта
У команды появились общие компоненты и правила, на которые можно опираться при редизайне. Новые экраны можно собирать последовательно, не принимая заново одни и те же решения.
Главный вывод: дизайн-система развивается сильнее, когда существующие компоненты регулярно пересматриваются, а новые паттерны появляются из реальных продуктовых задач.