
Несколько крупных клиентов пожаловались на список серверов:
Мы осознали, что панель создавалась для небольших инфраструктур и теперь плохо подходит для крупных клиентов.

Две основные группы пользователей:

В первую очередь я посмотрела сессии клиентов, чтобы выявить текущие пути и проблемы.

Далее я пообщалась с инженерами, бэкенд и фронтенд разработчиками, чтобы понять архитектуру продукта, возможности, ограничения и связи с другими продуктами.

Многие наши клиенты используют несколько облаков одновременно. Поэтому я провела анализ конкурентов, чтобы изучить существующие и привычные паттерны.

Я провела 5 интервью с системными администраторами, работающими с разными инфраструктурами, и выявила 5 основных сценариев работы в панели:

На основании полученных данных я подготовила несколько вариантов новой структуры, обсудила их с командой. Наиболее удачный протестировала на пользователях.

В ходе тестирования я получила много полезного фидбека, который учла при подготовке итогового решения.

Наладить работу неисправного сервера это одна из основных задач, с которой приходят в панель. Чтобы предположить возможные причины проблем, смотрят на ОС (1) и тип загрузочного диска (2), и затем подключаются к консоли сервера (3).

IP-адреса зачастую отражают роль сервера в инфраструктуре. Поэтому мы вместе со своей коллегой придумали систему визуального разделения адресов:
Это позволило отображать все адреса в одном столбце, при этом сохраняя возможность сканировать список по конкретному типу адреса. Кроме того, публичный сервер (как правило, основной в инфраструктуре) стал более заметным.



Реальное ускорение загрузки потребовало бы сильных изменений на бэке. Поэтому попробовали увеличить воспринимаемую скорость за счет асинхронной подгрузки элементов интерфейса.
