AERODISK
ENGINE
CASE STUDY // INTERFACE REDESIGN
Когда первая гипотеза оказалась не лучшим решением
Развитие процесса настройки СХД в AERODISK Engine на основе пользовательских исследований и обратной связи инженеров.
Engine — система управления СХД. Через интерфейс инженеры настраивают оборудование, управляют ресурсами хранения и контролируют состояние инфраструктуры.
Во время исследования стало понятно, что при настройке сложных конфигураций инженерам приходилось регулярно возвращаться к уже заполненным параметрам, что увеличивало время выполнения задачи. 
Цель проекта — найти более удобный сценарий работы.
Моя роль
Product Designer
• UX-исследование
• Проектирование сценариев
• UI-дизайн
• Прототипирование
• Тестирование с инженерами
Команда
Команда продукта
• Product Owner
• 2 инженера-настройщика СХД
• Системный аналитик
• Разработчики
Ответственность
UX Research & Product Design
Разработка интерфейсной системы, проектирование пользовательских сценариев
Продукт
Настройка систем хранения данных
Физические и логические ресурсы хранения, Enterprise-инфраструктура
PG
Следующий кейс →
AERODISK
ENGINE
CASE STUDY // INTERFACE REDESIGN
Когда первая гипотеза оказалась не лучшим решением
Развитие процесса настройки СХД в AERODISK Engine на основе пользовательских исследований и обратной связи инженеров.
Engine — система управления СХД. Через интерфейс инженеры настраивают оборудование, управляют ресурсами хранения и контролируют состояние инфраструктуры.
Во время исследования стало понятно, что при настройке сложных конфигураций инженерам приходилось регулярно возвращаться к уже заполненным параметрам, что увеличивало время выполнения задачи. Цель проекта — найти более удобный сценарий работы.
Моя роль
Product Designer
• UX-исследование
• Проектирование сценариев
• UI-дизайн
• Прототипирование
• Тестирование с инженерами
Команда
Команда продукта
• Product Owner
• 2 инженера-настройщика СХД
• Системный аналитик
• Разработчики
Ответственность
UX Research & Product Design
Разработка интерфейсной системы, проектирование пользовательских сценариев
Продукт
Настройка систем хранения данных
Физические и логические ресурсы хранения, Enterprise-инфраструктура
Исходный интерфейс
Исходный процесс настройки СХД
Первоначальный сценарий был построен вокруг одной формы с большим количеством параметров. Такой подход хорошо подходил для последовательного заполнения, однако при работе со сложными конфигурациями инженерам приходилось часто возвращаться к уже заполненным разделам.
При большом количестве параметров увеличивалась длина формы
Для сравнения настроек приходилось возвращаться к предыдущим разделам
Часть информации находилась вне текущей области просмотра
Последовательный сценарий не всегда соответствовал реальному процессу настройки
СХЕМА ЭВОЛЮЦИИ
Эволюция решения: от исходного экрана к рабочему пространству.
1
Исходный экран
2
Гипотеза: 
мастер настройки
3
Проверка на практике
4
Обновлённое рабочее пространство
5
Финальное решение
Исходный интерфейс
Исходный процесс настройки СХД
Первоначальный сценарий был построен вокруг одной формы с большим количеством параметров. Такой подход хорошо подходил для последовательного заполнения, однако при работе со сложными конфигурациями инженерам приходилось часто возвращаться к уже заполненным разделам.
!
При большом количестве параметров увеличивалась длина формы
!
Для сравнения настроек приходилось возвращаться к предыдущим разделам
!
Часть информации находилась вне текущей области просмотра
!
Последовательный сценарий не всегда соответствовал реальному процессу настройки
СХЕМА ЭВОЛЮЦИИ
Эволюция решения: от исходного экрана к рабочему пространству.
1
Исходный экран
2
Гипотеза: мастер настройки
3
Проверка на практике
4
Обновлённое рабочее пространство
5
Финальное решение
Первая гипотеза
Последовательный мастер должен был упростить процесс настройки.
Первой гипотезой стало разделение длинной формы настройки на последовательные шаги (Wizard), чтобы снизить когнитивную нагрузку и сделать процесс более понятным.
Проверка гипотезы показала, что последовательный сценарий подходит не для всех задач настройки.
Первая гипотеза
Последовательный мастер должен был упростить процесс настройки.
Первой гипотезой стало разделение длинной формы настройки на последовательные шаги (Wizard), чтобы снизить когнитивную нагрузку и сделать процесс более понятным.
Проверка гипотезы показала, что последовательный сценарий подходит не для всех задач настройки.
Исследование
Участники
3 инженера
ТЕСТИРОВАНИЕ
5 часов
ВЫЯВЛЕНО ПРОБЛЕМ
12
Интервью
30 минут
По результатам внутренних тестов
Проверка гипотез изменила направление решения
Во время тестирования стало заметно, что инженеры не выполняют настройку строго последовательно. Они регулярно возвращаются к уже заполненным параметрам, сравнивают значения и переключаются между связанными разделами.
01
Не хватает общего контекста
02
Неудобно сравнивать параметры
03
Много переключений между шагами
04
Последовательный сценарий не всегда удобен при больших конфигурациях.
“
«Как дизайн — нормально, красиво. Как пользоваться — всё плохо»
Инженер - настройщик СХД
Эта обратная связь показала, что проблема заключалась не во внешнем виде интерфейса, а в самом сценарии работы. Мы пересмотрели первоначальную гипотезу и начали искать решение, которое лучше соответствовало реальной работе инженеров.
Исследование
Участники
3 инженера
Тестирование
5 часов
Выявлено проблем
12
Интервью
30 минут
По результатам внутренних тестов
Проверка гипотез изменила направление решения
Во время тестирования стало заметно, что инженеры не выполняют настройку строго последовательно. Они регулярно возвращаются к уже заполненным параметрам, сравнивают значения и переключаются между связанными разделами.
01
Не хватает общего контекста
02
Неудобно сравнивать параметры
03
Много переключений между шагами
04
Последовательный сценарий не всегда удобен при больших конфигурациях.
“
«Как дизайн — нормально, красиво.
Как пользоваться — всё плохо»
Инженер - настройщик СХД
Эта обратная связь показала, что проблема заключалась не во внешнем виде интерфейса, а в самом сценарии работы. Мы пересмотрели первоначальную гипотезу и начали искать решение, которое лучше соответствовало реальной работе инженеров.
Переход к рабочему пространству
Результаты тестирования показали, что при работе со сложными конфигурациями инженеры регулярно возвращаются к уже заполненным параметрам и свободно переключаются между связанными разделами. Это привело команду к новой гипотезе — рабочему пространству с сохранением общего контекста настройки.
Что мы увидели во время проверки гипотезы
Инженеры постоянно возвращались назад
Сравнивали параметры между шагами
Переключались между разделами
Принимали решения не последовательно
Следующим этапом стало проектирование рабочего пространства
Мастер подтвердил важную гипотезу и помог понять реальный рабочий процесс инженеров. Именно благодаря этой проверке появилось более подходящее решение.
FLOW МАСТЕРА-
СОЗДАНИЯ
Пошаговый сценарий
1
Доступная ёмкость
Админ видит исходную доступную ёмкость пула
12.4 TB
2
Размер LUN
Ёмкость больше не видна. Приходится переходить назад.
Назад → Запомнить доступное → Далее → Ввести размер LUN
РАБОЧЕЕ
ПРОСТРАНСТВО
Рабочее пространство
Доступная ёмкость
Контроль лимитов в реальном времени
12.4 TB
Конфигурация RAID
Тип группы и отказоустойчивость
RAID 6 (8+2)
Выбранные диски
Состав, слоты размещения, серийники
10x SAS SSD
Параметры группы
Связывание пула и настроек кэша
POOL_STG_01
Итоговая конфигурация
Динамический калькулятор результатов
8.2 TB Net
Before/After: мастер → рабочее пространство
БЫЛО
Мастер
СТАЛО
Рабочее пространство
Рабочее пространство сохранило общий контекст настройки: связанные параметры стали доступны на одном экране, а инженеры смогли свободно переключаться 
между ними без потери хода работы.
Переход к рабочему пространству
Результаты тестирования показали, что при работе со сложными конфигурациями инженеры регулярно возвращаются к уже заполненным параметрам и свободно переключаются между связанными разделами. Это привело команду к новой гипотезе — рабочему пространству с сохранением общего контекста настройки.
Что мы увидели во время проверки гипотезы
Инженеры постоянно возвращались назад
Сравнивали параметры между шагами
Переключались между разделами
Принимали решения не последовательно
Следующим этапом стало проектирование рабочего пространства
Мастер подтвердил важную гипотезу и помог понять реальный рабочий процесс инженеров. Именно благодаря этой проверке появилось более подходящее решение.
FLOW
МАСТЕРА-СОЗДАНИЯ
Пошаговый сценарий
1
Доступная ёмкость
Админ видит исходную доступную ёмкость пула
12.4 TB
2
Размер LUN
Ёмкость больше не видна. Приходится переходить назад.
Назад → Запомнить доступное → Далее → Ввести размер LUN
РАБОЧЕЕ
ПРОСТРАНСТВО
Рабочее пространство
1
Доступная ёмкость
12.4 TB
2
Конфигурация RAID
RAID 6 (8+2)
3
Выбранные диски
10x SAS SSD
4
Параметры группы
POOL_STG_01
5
Итоговая конфигурация
8.2 TB Net
Before/After: мастер - рабочее пространство
БЫЛО
Мастер
СТАЛО
Рабочее пространство
Рабочее пространство сохранило общий контекст настройки: связанные параметры стали доступны на одном экране, а инженеры смогли свободно переключаться между ними без потери хода работы.
Рабочее пространство, соответствующее реальному сценарию настройки
Финальное решение объединило связанные параметры на одном экране. Инженеры получили возможность сравнивать данные, возвращаться к предыдущим настройкам 
и принимать решения без потери контекста.
  • Все связанные параметры доступны одновременно
  • Сравнение дисков происходит без переключения между шагами
  • Контекст настройки сохраняется на всём протяжении сценария
  • Итоговые параметры рассчитываются в процессе настройки
Основные параметры
Название
dg-prod-ssd-01
Тип RAID
RAID 6 (Double Parity)
Структура
8 + 2 (Data + Parity)
Доп. параметры
Write cache: Enabled
ДОСТУПНЫЕ ДИСКИ
Тип дисков
SAS SSD Enterprise
Объём единицы
1.92 TB
Диапазон Slots
Encl 1: Slot 1-24
Группировка
By Serial / Enclosure
ВЫБРАННЫЕ ДИСКИ
Раздел V-DEV
vdev-01
Состав группы
10 Active Drives
Количество
10 шт. (SSD)
Характеристики
DWPD: 3.0 / 12G SAS
Итоги конфигурации
Выбранный RAID
RAID 6
Всего дисков
10 SSD
Итоговая ёмкость
15.36 TB Net
Ограничения
min 4, max 16
Все связанные действия выполняются в одном рабочем пространстве без потери контекста
Что изменилось
Пользовательский сценарий стал соответствовать реальному процессу работы инженеров
Проверка с инженерами позволила скорректировать архитектуру сценария до выхода в продукт.
Рабочее пространство стало основой для развития следующих 
сценариев конфигурирования
Подход к проектированию можно применять в следующих функциях продукта
Этот проект показал, что проверка гипотез может изменить не внешний вид интерфейса, а саму архитектуру пользовательского сценария.
Рабочее пространство, соответствующее реальному сценарию настройки
Финальное решение объединило связанные параметры на одном экране. Инженеры получили возможность сравнивать данные, возвращаться к предыдущим настройкам и принимать решения без потери контекста.
Все связанные параметры доступны одновременно
Сравнение дисков происходит без переключения между шагами
Контекст настройки сохраняется на всём протяжении сценария
Итоговые параметры рассчитываются в процессе настройки
Основные параметры
Название
dg-prod-ssd-01
Тип RAID
RAID 6 (Double Parity)
Структура
8 + 2 (Data + Parity)
Доп. параметры
Write cache: Enabled
ДОСТУПНЫЕ ДИСКИ
Тип дисков
SAS SSD Enterprise
Объём единицы
1.92 TB
Диапазон Slots
Encl 1: Slot 1-24
Группировка
By Serial / Enclosure
ВЫБРАННЫЕ ДИСКИ
Раздел V-DEV
vdev-01
Состав группы
10 Active Drives
Количество
10 шт. (SSD)
Характеристики
DWPD: 3.0 / 12G SAS
Итоги конфигурации
Выбранный RAID
RAID 6
Всего дисков
10 SSD
Итоговая ёмкость
15.36 TB Net
Ограничения
min 4, max 16
Все связанные действия выполняются в одном рабочем пространстве без потери контекста
Что изменилось
Пользовательский сценарий стал соответствовать реальному процессу работы инженеров
Проверка с инженерами позволила скорректировать архитектуру сценария до выхода в продукт.
Рабочее пространство стало основой для развития следующих сценариев конфигурирования
Подход к проектированию можно применять в следующих функциях продукта
Этот проект показал, что проверка гипотез может изменить не внешний вид интерфейса, а саму архитектуру пользовательского сценария.
По результатам внутренних тестов
−73%
Сокращение времени операции
45 мин → 12 мин на настройку
−60%
Снижение ошибок конфигурации
Меньше критических сбоев
5×
Ускорение онбординга
2 недели → 3 дня обучения
RESULT
Изначально задача заключалась в улучшении существующего мастера настройки. Но исследование показало, что проблема заключалась не в количестве шагов, а в самой модели взаимодействия. Вместо доработки мастера мы спроектировали рабочее пространство, которое соответствует реальному сценарию работы инженеров.
Первая итерация помогла упорядочить интерфейс ENGINE и сделать его понятнее. Но работа инженеров с продуктом показала, что визуальных изменений недостаточно. Основной проблемой оказалась модель взаимодействия: последовательные мастера, потеря контекста между шагами и интерфейс, не рассчитанный на сотни технических сущностей. Обратная связь реальных пользователей стала причиной пересмотра сложных сценариев и отказа от мастера в пользу отдельных рабочих пространств.
Ключевой вывод
Проверка гипотез меняет не только интерфейс — она помогает найти правильную модель взаимодействия
180+
экранов
20+
компонентов
15
сценариев
40%
эффективности
«Хороший интерфейс для сложной системы — не тот, который визуально скрывает сложность.
Он помогает специалисту управлять сложностью, а не создавать новую»
ВЫВОД
Иногда проверка гипотез показывает, что улучшать нужно не существующее решение, а сам подход к проектированию сценария.
По результатам внутренних тестов
−73%
Сокращение времени операции
45 мин → 12 мин на настройку
−60%
Снижение ошибок конфигурации
Меньше критических сбоев
5×
Ускорение онбординга
2 недели → 3 дня обучения
RESULT
Изначально задача заключалась в улучшении существующего мастера настройки. Но исследование показало, что проблема заключалась не в количестве шагов, а в самой модели взаимодействия. Вместо доработки мастера мы спроектировали рабочее пространство, которое соответствует реальному сценарию работы инженеров.
Первая итерация помогла упорядочить интерфейс ENGINE и сделать его понятнее. Но работа инженеров с продуктом показала, что визуальных изменений недостаточно. Основной проблемой оказалась модель взаимодействия: последовательные мастера, потеря контекста между шагами и интерфейс, не рассчитанный на сотни технических сущностей. Обратная связь реальных пользователей стала причиной пересмотра сложных сценариев и отказа от мастера в пользу отдельных рабочих пространств.
Ключевой вывод
Проверка гипотез меняет не только интерфейс — она помогает найти правильную модель взаимодействия
180+
экранов
20+
компонентов
15
сценариев
40%
эффективности
«Хороший интерфейс для сложной системы — не тот, который визуально скрывает сложность.
Он помогает специалисту управлять сложностью, а не создавать новую»
ВЫВОД
Иногда проверка гипотез показывает, что улучшать нужно не существующее решение, а сам подход к проектированию сценария.
Made on
Tilda