AERODISK
vAIR
Роль - Product Designer / Команда - PM - Analyst Developers / Период 2022–2023
Turning complexity into clarity.
Редизайн Enterprise-платформы виртуализации: от разрозненного интерфейса к масштабируемой дизайн-системе
Систематизация интерфейса платформы управления виртуальной инфраструктурой.
vAIR — Enterprise-платформа управления виртуальной инфраструктурой, используемая системными администраторами и инженерами для управления виртуальными машинами, сетями, хранилищами и вычислительными узлами в корпоративной инфраструктуре.
МОЯ РОЛЬ
Senior Product Designer
UX • UI • Interface System
КОМАНДА
Product Owner · Аналитики
• PM • Analyst • Developers
ОТВЕТСТВЕННОСТЬ
Исследование и проектирование UX
• UX • UI • Design System 
• Developer Handoff
ПРОДУКТ
Enterprise · Виртуализация
Управление инфраструктурой
Используется в ЦОДах
Мой вклад
  • Спроектировал новую навигацию
  • Разработал Dashboard мониторинга
  • Переработал сценарий Wizard
  • Создал UI Kit и Design System
  • Унифицировал формы
  • Унифицировал таблицы
PG
Следующий кейс →
AERODISK
vAIR
Роль - Product Designer / Команда - PM - Analyst Developers / Период 2022–2023
Turning complexity into clarity.
Редизайн Enterprise-платформы виртуализации: от разрозненного интерфейса к масштабируемой дизайн-системе
Систематизация интерфейса платформы управления виртуальной инфраструктурой.
vAIR — Enterprise-платформа управления виртуальной инфраструктурой, используемая системными администраторами и инженерами для управления виртуальными машинами, сетями, хранилищами и вычислительными узлами в корпоративной инфраструктуре.
МОЯ РОЛЬ
Senior Product Designer
UX • UI • Interface System
КОМАНДА
Product Owner · Аналитики
• PM • Analyst • Developers
ОТВЕТСТВЕННОСТЬ
Исследование и проектирование UX
• UX • UI • Design System • Developer Handoff
ПРОДУКТ
Enterprise · Виртуализация
Управление инфраструктурой / Используется в ЦОДах
Мой вклад
• Спроектировал новую навигацию
• Разработал Dashboard мониторинга
• Переработал сценарий Wizard
• Создал UI Kit и Design System
• Унифицировал формы
• Унифицировал таблицы
КОНТЕКСТ
vAIR UX Case · 2022
Моя задача
• Переработать интерфейс • Создать единый UI Kit • Построить дизайн-систему • Унифицировать сценарии • Сделать продукт масштабируемым
Анализ текущего состояния системы выявил критические барьеры, мешающие пользователям эффективно работать с продуктом.
Продукт работал. Но каждый понимал его по-своему.
Когда я присоединился к проекту, продукт уже активно развивался. Новые функции создавались по мере роста системы, поэтому отдельные сценарии и интерфейсы постепенно формировались независимо друг от друга. В результате появились различия в навигации, терминологии и пользовательских паттернах, что усложняло освоение продукта и работу с ним.
Проблема
  • По мере роста продукта возникла потребность в единых UX-паттернах и принципах проектирования.
  • Отдельные разделы развивались независимо, что привело к различиям в пользовательских сценариях.
  • Навигация перестала полностью отражать структуру системы по мере расширения функциональности.
  • Для дальнейшего масштабирования продукта требовалась единая компонентная база и дизайн-система.
АУДИТ ИНТЕРФЕЙСА
Почему продукту потребовалось переосмысление UX
Нет единого подхода
Похожие задачи решались по-разному. Пользователям приходилось каждый раз адаптироваться к новым логическим правилам.
Сложно сканировать
Разная иерархия, разные паттерны и отсутствие смысловых группировок затрудняли быстрое чтение экранов.
Несогласованные маркеры
Одинаковые сущности и статусы на разных экранах отображались по-разному, ломая ментальную модель.
Высокая когнитивная нагрузка
Пользователю требовалось значительное время и концентрация просто на то, чтобы расшифровать интерфейс перед началом работы.
Накопление локальных интерфейсных решений
По мере развития продукта возникли различия в компонентах и паттернах интерфейса, что усложняло их сопровождение и дальнейшее развитие.
Моя задача заключалась не в переработке отдельных экранов, а в создании единого подхода к развитию интерфейсов, который позволил бы продукту масштабироваться
КОНТЕКСТ
vAIR UX Case · 2022
Моя задача
• Переработать интерфейс • Создать единый UI Kit • Построить дизайн-систему • Унифицировать сценарии • Сделать продукт масштабируемым
Анализ текущего состояния системы выявил критические барьеры, мешающие пользователям эффективно работать с продуктом.
Продукт работал. Но каждый понимал его по-своему.
Когда я присоединился к проекту, продукт уже активно развивался. Новые функции создавались по мере роста системы, поэтому отдельные сценарии и интерфейсы постепенно формировались независимо друг от друга. В результате появились различия в навигации, терминологии и пользовательских паттернах, что усложнило освоение продукта и работу с ним.
Проблема
• По мере роста продукта возникла потребность в единых UX-паттернах и принципах проектирования.
• Отдельные разделы развивались независимо, что привело к различиям в пользовательских сценариях.
• Навигация перестала полностью отражать структуру системы по мере расширения функциональности.
• Для дальнейшего масштабирования продукта требовалась единая компонентная база и дизайн-система.
АУДИТ ИНТЕРФЕЙСА
Почему продукту потребовалось переосмысление UX
Нет единого подхода
Похожие задачи решались по-разному. Пользователям приходилось каждый раз адаптироваться к новым логическим правилам.
Сложно сканировать
Разная иерархия, разные паттерны и отсутствие смысловых группировок затрудняли быстрое чтение экранов.
Несогласованные маркеры
Одинаковые сущности и статусы на разных экранах отображались по-разному, ломая ментальную модель.
Высокая когнитивная нагрузка
Пользователю требовалось значительное время и концентрация просто на то, чтобы расшифровать интерфейс перед началом работы.
Накопление интерфейсных решений
По мере развития продукта возникли различия в компонентах и паттернах интерфейса, что усложняло их сопровождение и дальнейшее развитие.
Моя задача заключалась не в переработке отдельных экранов, а в создании единого подхода к развитию интерфейсов, который позволил бы продукту масштабироваться
проектированиЕ
МОЙ ПОДХОД К СОЗДАНИЮ НОВЫХ ФУНКЦИЙ
Изучить проблему
Определить приоритеты
Спроектировать решение
Передать в разработку
Проверить реализацию
Методология и ценности
ПРИНЦИПЫ, КОТОРЫЕ ЛЕЖАТ В ОСНОВЕ МОИХ РЕШЕНИЙ
Понятность прежде всего
Интерфейс должен помогать пользователю быстро понять, что происходит и что делать.
Единообразие и системность
Общие паттерны и компоненты снижают когнитивную нагрузку и упрощают обучение.
Связанные сущности в одном сценарии
Пользователь должен решать задачу, не переключаясь между разделами.
Контекстность
Показываем пользователю только то, что необходимо в текущем сценарии.
Дизайн - часть разработки
Figma стала источником истины для команды и основой реализации.
По мере развития продукта дизайн стал частью процесса принятия продуктовых решений и сопровождения разработки
проектированиЕ
МОЙ ПОДХОД К СОЗДАНИЮ НОВЫХ ФУНКЦИЙ
1. Изучить проблему
2. Определить приоритеты
3. Спроектировать решение
4. Передать в разработку
5. Проверить реализацию
Методология и ценности
ПРИНЦИПЫ, КОТОРЫЕ ЛЕЖАТ В ОСНОВЕ МОИХ РЕШЕНИЙ
Понятность прежде всего
Интерфейс должен помогать пользователю быстро понять, что происходит и что делать.
Единообразие и системность
Общие паттерны и компоненты снижают когнитивную нагрузку и упрощают обучение.
Связанные сущности в одном сценарии
Пользователь должен решать задачу, не переключаясь между разделами.
Контекстность
Показываем пользователю только то, что необходимо в текущем сценарии.
Дизайн - часть разработки
Figma стала источником истины для команды и основой реализации.
По мере развития продукта дизайн стал частью процесса принятия продуктовых решений и сопровождения разработки
ПРОЦЕСС
01 / FIND
Навигация, которую можно сканировать
Переосмыслил навигацию, сохранив привычную структуру продукта и усилив её иерархию и сканируемость.
Проблемы
КАК БЫЛО
Недостаточно выраженная иерархия
Сложно понять структуру с первого взгляда
Высокая плотность информации Большое количество пунктов и отсутствие группировок
Различия в визуальных маркерах
Разные значки и отступы не дают быстро обнаруживать паттерны
Решение
КАК СТАЛО
01
Визуальные якоря
Ключевые разделы получили понятные иконки и визуальные маркеры
02
Понятная иерархия
Категории и уровни навигации визуально отделены друг от друга
03
Единый паттерн
Типографика, отступы и маркеры формируют одинаковую логику для всех разделов
Почему это решение?
Сильная иерархия
Понятное визуальное разделение на группы
Единые маркеры
Объекты навигации намного легче распознавать
Понятные active-состояния
Текущий раздел всегда заметен на экране
Быстрый доступ
Ключевые группы хорошо различимы в интерфейсе
ПОЧЕМУ ИМЕННО ТАК
Уменьшили глубину навигации
Сделали структуру масштабируемой
Сгруппировали сущности
Основные сценарии стали быстрее доступны
Пользователи хорошо знали существующую структуру продукта, поэтому задача заключалась не в радикальном изменении навигации, а в повышении её читаемости, согласованности и удобства работы.
ПРОЦЕСС
01 / FIND
Навигация, которую можно сканировать
Переосмыслил навигацию, сохранив привычную структуру продукта и усилив её иерархию и сканируемость.
КАК БЫЛО
Проблемы
Недостаточно выраженная иерархия
Сложно понять структуру с первого взгляда
Высокая плотность информации
Большое количество пунктов и отсутствие группировок
Различия в визуальных маркерах
Разные значки и отступы не дают быстро обнаруживать паттерны
КАК СТАЛО
Решение
01
Визуальные якоря
Ключевые разделы получили понятные иконки и визуальные маркеры
02
Понятная иерархия
Категории и уровни навигации визуально отделены друг от друга
03
Единый паттерн
Типографика, отступы и маркеры формируют одинаковую логику для всех разделов
Почему это решение?
Сильная иерархия
Понятное визуальное разделение на группы
Единые маркеры
Объекты навигации намного легче распознавать
Понятные active-состояния
Текущий раздел всегда заметен на экране
Быстрый доступ
Ключевые группы хорошо различимы в интерфейсе
ПОЧЕМУ ИМЕННО ТАК
Уменьшили глубину навигации
Сгруппировали сущности
Сделали структуру масштабируемой
Основные сценарии стали быстрее доступны
Пользователи хорошо знали существующую структуру продукта, поэтому задача заключалась не в радикальном изменении навигации, а в повышении её читаемости, согласованности и удобства работы.
02 / UNDERSTAND
От данных - к картине состояния системы
Переработал Dashboard, чтобы состояние инфраструктуры можно было оценить с первого взгляда.
Исходное состояние (ДО)
Администратору было сложно быстро оценить состояние системы.
Показатели отображались независимо друг от друга
Сложно понять общее состояние системы.
Не было визуального приоритета данных
Нет фокуса на главном.
Ключевые показатели требовали дополнительного поиска
Нужно постоянно искать важные данные.
После редизайна
Перестроил Dashboard, объединив ключевые показатели состояния системы в единую визуальную модель.
Целостная картина состояния системы
Критически важная информация стала доступна с первого взгляда.
Фокус на ключевых показателях
Основные ресурсы и состояния получили визуальный приоритет.
Логичные связи между ресурсами, узлами и событиями
Данные сгруппированы по контексту.
Единая логика представления данных
Повторяющиеся элементы используют общую визуальную логику.
Вместо увеличения количества показателей я сгруппировал данные по задачам администратора. Это позволило быстрее понимать состояние системы без поиска информации по нескольким разделам.
Результат
01
Меньше когнитивной нагрузки
02
Быстрее оценка состояния инфраструктуры
03
Меньше лишних действий при анализе состояния
04
Единая визуальная модель данных
Решение обсуждалось с инженерами и проверялось на сценариях ежедневной работы администраторов, чтобы сохранить привычный контекст и улучшить скорость восприятия информации.
02 / UNDERSTAND
От данных - к картине состояния системы
Переработал Dashboard, чтобы состояние инфраструктуры можно было оценить с первого взгляда.
Исходное состояние (ДО)
Администратору было сложно быстро оценить состояние системы.
Показатели отображались независимо друг от друга
Сложно понять общее состояние системы.
Не было визуального приоритета данных
Нет фокуса на главном.
Ключевые показатели требовали дополнительного поиска
Нужно постоянно искать важные данные.
После редизайна
Перестроил Dashboard, объединив ключевые показатели состояния системы в единую визуальную модель.
Целостная картина состояния системы
Критически важная информация стала доступна с первого взгляда.
Фокус на ключевых показателях
Основные ресурсы и состояния получили визуальный приоритет.
Логичные связи между ресурсами, узлами и событиями
Данные сгруппированы по контексту.
Единая логика представления данных
Повторяющиеся элементы используют общую визуальную логику.
Вместо увеличения количества показателей я сгруппировал данные по задачам администратора. Это позволило быстрее понимать состояние системы без поиска информации по нескольким разделам.
Результат
01
Меньше когнитивной нагрузки
02
Быстрее оценка состояния
03
Меньше лишних действий
04
Единая модель данных
Решение обсуждалось с инженерами и проверялось на сценариях ежедневной работы администраторов, чтобы сохранить привычный контекст и улучшить скорость восприятия информации.
03 / ACT
Из технической формы — в сценарий конфигурации
Создание виртуальной машины — один из ключевых сценариев платформы. По мере развития продукта процесс включил большое количество связанных параметров и сущностей. Моей задачей было организовать их в последовательный сценарий конфигурации, сохранив гибкость для администратора.
Особенности исходного сценария
Для выполнения сценария пользователю требовалось одновременно учитывать большое количество взаимосвязанных параметров.
01 - Много связанных параметров
Старый процесс был построен вокруг технических параметров и структуры системы.
02 - Создание связанных сущностей без выхода из сценария
Нужные связанные сущности можно создать непосредственно внутри текущего сценария.
Пользователь не теряет контекст основной задачи.
03 - Один паттерн для связанных сущностей
Выбрать существующую сущность или создать новую.
Один подход используется для дисков, виртуальных образов и сетей.
04 - Прогрессивное раскрытие и информированный выбор
Показываем только необходимые настройки. Расширенные параметры доступны по запросу, а выбор технических сущностей происходит с учётом их характеристик.
Вместо набора независимых технических форм был спроектирован единый сценарий конфигурации, где пользователь проходит этапы последовательно, а связанные параметры открываются по мере необходимости.
Результат
Меньше когнитивной нагрузки
Параметры сгруппированы вокруг этапов конфигурации.
Последовательное выполнение задачи
Пользователь проходит последовательный логический сценарий.
Меньше ошибок
Связанные параметры находятся в одном рабочем контексте
Единый подход
Повторяющиеся задачи используют общий UX-паттерн.
03 / ACT
Из технической формы — в сценарий конфигурации
Создание виртуальной машины — один из ключевых сценариев платформы. По мере развития продукта процесс включил большое количество связанных параметров и сущностей. Моей задачей было организовать их в последовательный сценарий конфигурации, сохранив гибкость для администратора.
Особенности исходного сценария
Для выполнения сценария пользователю требовалось одновременно учитывать большое количество взаимосвязанных параметров.
01 - Много связанных параметров
Старый процесс был построен вокруг технических параметров и структуры системы.
02 - Создание связанных сущностей без выхода
Нужные связанные сущности можно создать непосредственно внутри текущего сценария. Пользователь не теряет контекст основной задачи.
03 - Один паттерн для связанных сущностей
Выбрать существующую сущность или создать новую. Один подход используется для дисков, виртуальных образов и сетей.
04 - Прогрессивное раскрытие
Показываем только необходимые настройки. Расширенные параметры доступны по запросу, а выбор технических сущностей происходит с учётом их характеристик.
Вместо набора независимых технических форм был спроектирован единый сценарий конфигурации, где пользователь проходит этапы последовательно, а связанные параметры открываются по мере необходимости.
Результат
Меньше когнитивной нагрузки
Параметры сгруппированы вокруг этапов конфигурации.
Последовательное выполнение
Пользователь проходит последовательный логический сценарий.
Меньше ошибок
Связанные параметры находятся в одном рабочем контексте.
Единый подход
Повторяющиеся задачи используют общий UX-паттерн.
04 / SCALE
Система, которая масштабирует продукт
Чтобы продукт можно было развивать без роста сложности интерфейса, я создал Design System, унифицировал повторяющиеся паттерны и встроил систему компонентов в процесс разработки.
Design System
Компоненты
UI Patterns
Повторяющиеся сценарии
Product States
Единая система статусов
Foundations
Цвета • Типографика • Tokens
Архитектура дизайн-системы
LAYER_01
Foundations
Цвета, типографика, отступы, сетка, иконки, токены.
// Colors
31C48D
057A55
014737
DB9730
DB8B12
F05252
F14E46
91979B
76A9FA
287FE8
2B4591
2F2F31
343435
3F3F42
505356
747A7D
AAAAAA
BFBFBF
D0D0D0
E4E4E4
F1F1F1
FFFFFF
LAYER_02
Components
Кнопки, поля, таблицы, формы, элементы ввода и управления.
// BUTTON_COMPONENT
Действие
Действие
Действие
Действие
Primary
Primary / Icon
Secondary
Secondary / Icon
Действие
Действие
Действие
Действие
Hover
Disabled
// INPUT
Заголовок инпута
Текст инпута
Select
Выберите значение
Текст инпута
Введите значение
Текст ошибки 70 символов MAX
LAYER_03
// VM_CREATION
Resource
Configuration
Validation
Deploy
// OBJECT_MANAGEMENT
Table
Drawer
Edit
Apply
// CONFIGURATION
Overview
Parameters
Review
Apply
// Infrastructure Setup
Storage
Network
Compute
Review
UX Patterns
Паттерны для типовых задач и сценариев.
LAYER_04
Product states
Уведомления, ошибки, системные состояния.
Приоритет уведомлений для пользователя
Низкий
Средний
Выше среднего
Высокий
1. Уведомления о выполненных процессах
2. Предупреждения
3. Системные предупреждения
4. Модальные окна критических ошибок
04 / SCALE
Система, которая масштабирует продукт
Чтобы продукт можно было развивать без роста сложности интерфейса, я создал Design System, унифицировал повторяющиеся паттерны и встроил систему компонентов в процесс разработки.
Design System
Компоненты
UI Patterns
Сценарии
Product States
Статусы
Foundations
Токены
Архитектура дизайн-системы
LAYER_01
Foundations
Цвета, типографика, отступы, сетка, иконки, токены.
// COLORS
// FONTS
H1 - Exo 2 Bold (28px)
P1 - Exo 2 Regular (14px)
LAYER_02
Components
Кнопки, поля, таблицы, формы, элементы ввода и управления.
// Buttons
Действие
Действие
Disabled
// Input Fields
Input header 12/lineHeight-auto / 70 max
Input text 12/lineHeight-auto - 67 max
Input header 12/lineHeight-auto / 70 max
Input text 12/lineHeight-auto - 67 max
LAYER_03
UX Patterns
Паттерны для типовых задач и сценариев.
// VM Creation Flow
Resource
Config
Deploy
// Infrastructure Setup
Storage
Compute
Review
LAYER_04
Product states
Уведомления, ошибки, системные состояния.
Приоритет уведомлений для пользователя
Низкий
Средний
Выше среднего
Высокий
1. Уведомления о процессах
2. Предупреждения
3. Системные предупреждения
4. Модальные окна ошибок
Итоги проекта
Что изменилось
Интерфейс стал единообразным.
Разработчики работают с общей библиотекой компонентов.
Новые функции проектируются быстрее.
Продукт проще масштабировать.
Повторяющиеся задачи используют единые UX-паттерны.
для продукта и команды
UI Kit стал источником истины для команды
Компоненты и макеты в Figma стали использоваться как основа реализации.
UX-сценарии стали частью процесса проектирования
Пользовательский сценарий стал отдельным этапом проектирования функции.
Повторяющиеся задачи получили общие паттерны
Таблицы, формы, состояния и связанные сущности стали использовать единые подходы.
Новые функции создаются на основе существующих паттернов
Повторное использование компонентов и паттернов ускорило проектирование новых функций.
Результатом проекта стал не только новый интерфейс, а система проектирования, которая позволила последовательно развивать продукт 
без роста сложности.
Проект показал, что развитие Enterprise-продукта начинается не с отдельных экранов, а с понимания системы, пользовательских 
сценариев и единых принципов проектирования. Именно такой подход позволил сделать интерфейс более понятным, а дальнейшее 
развитие продукта — более предсказуемым и масштабируемым.
Итоги проекта
Что изменилось
Интерфейс стал единообразным.
Разработчики работают с общей библиотекой компонентов.
Новые функции проектируются быстрее.
Продукт проще масштабировать.
Повторяющиеся задачи используют единые UX-паттерны.
для продукта и команды
UI Kit стал источником истины для команды
Компоненты и макеты в Figma стали использоваться как основа реализации.
UX-сценарии стали частью процесса проектирования
Пользовательский сценарий стал отдельным этапом проектирования функции.
Повторяющиеся задачи получили общие паттерны
Таблицы, формы, состояния и связанные сущности стали использовать единые подходы.
Новые функции создаются на основе существующих паттернов
Повторное использование компонентов и паттернов ускорило проектирование новых функций.
Результатом проекта стал не только новый интерфейс, а система проектирования, которая позволила последовательно развивать продукт
без роста сложности.
Проект показал, что развитие Enterprise-продукта начинается не с отдельных экранов, а с понимания системы, пользовательских
сценариев и единых принципов проектирования. Именно такой подход позволил сделать интерфейс более понятным, а дальнейшее
развитие продукта — более предсказуемым и масштабируемым.
Made on
Tilda