Skala^R Приложение для наблюдаемости (observability) ИТ-инфраструктуры
Skala^R — это R&D-подразделение материнской компании, крупного системного интегратора, чьими продуктами сегодня ежедневно пользуются более 100 миллионов пользователей.
Отрасль
ИИ · B2B
статус
Работающая замкнутая система
Год
2022 – настоящее время
Роль
Исследования, прототипирование
Проблема
За эти годы система постепенно превратилась в разрозненную среду — несколько приложений работали на разных версиях интерфейса, и у них не было общего языка дизайна. Интерфейс выглядел устаревшим по сравнению с современными рыночными стандартами, отзывы пользователей были неоднозначными, а отдел продаж уже начал ощущать трение. Редизайн был не просто косметическим обновлением — он был необходимым условием, чтобы продукт оставался конкурентоспособным.
Решение
Переосмысление
Очевидным шагом было бы параллельно обновить каждую систему. Я возразил: без дизайн-системы в основе мы бы просто перекрасили ту же фрагментацию в новый цвет. Настоящим условием было единое источник истины, от которого мог бы работать каждый продукт.
Подход
Я начал с общего визуального стиля и ощущения. Это одновременно решало две задачи: давало команде конкретное визуальное направление, на которое можно было опираться, и предоставляло мне осязаемый артефакт, с которым можно было идти к руководству и защищать инвестиции в саму дизайн-систему.
Процесс
После первых макетов я получил от команды жёсткую обратную связь: уведомления были не второстепенным каналом — они были самой точкой входа в управление инцидентами. Рабочая область сервера выглядела как основной экран, но в реальной работе инженеры начинали с оповещения и двигались дальше. Поэтому я пошёл на компромисс: перенёс панель уведомлений влево, в основной слот навигации. Плата была визуальной — теперь рабочая область сервера читается почти как детальный вид панели уведомлений — но это соответствовало тому, как на самом деле разворачивается работа.
Состояние инцидента прямо в рабочей области отображается как крупный, пульсирующий красный индикатор. Это выглядит как что-то из фантазийного UI — и именно так и задумано. В интерфейсе, где красный и так повсюду (предупреждения, пороги, состояния ошибок), инженерам нужен безошибочный сигнал, где находится настоящий красный. Такой визуальный акцент — не украшение, а решение в пользу иерархии.
Компромиссы
Графики были очевидным кандидатом на редизайн, поскольку нарушали визуальную целостность новой системы. Я решил их не трогать. Библиотека графиков не относилась к зоне ответственности фронтенда; она была напрямую подключена к Data Lake и определяла, как команда data engineering извлекала данные и работала с ними. Замена означала бы переподключение их рабочих процессов, вмешательство в работу целого отдела и, вдобавок, прогон изменений через полный QA-цикл. Затраты были высокими, польза — чисто косметической, и математика не оправдывала такой шаг — красота не может стоить любой цены.
Была и причина, связанная с рабочим процессом, оставить графики на месте. Инженеры хотели, чтобы таблица данных располагалась прямо под графиком: они постоянно сверяли отдельные точки данных между этими двумя элементами, и нарушение такого соседства замедлило бы их работу. Этот "некрасивый" график был несущим элементом — он был частью того, как команда на самом деле читала данные.
Я отметил визуальную несогласованность как известный дизайн-долг — проблему, которую стоит решить позже, когда появится функциональный повод затронуть этот слой, а не просто ради смены цветов диаграммы.
Первый положительный отзыв
Первый раунд отзывов после редизайна дал результат, которого я не ожидал: инженеры сказали, что новый интерфейс кажется им знакомым, потому что он читается как окно терминала Linux. 88% участников опроса сказали, что с большей вероятностью будут пользоваться новой версией, чем старой, — именно потому, что она ощущается родной для их среды. На самом деле это не терминал — это упрощённый визуальный язык, который заимствует те же ориентиры: моноширинные акценты, плотную компоновку информации, тёмную поверхность, минимум визуального оформления. Небольшой набор решений, и заметный рост использования.
Рестайлинг
Единственной функцией, которая получила самый тёплый отклик, стала панель фильтрации по статусу в верхней части таблицы данных. Она позволяет пользователям одним щелчком фильтровать таблицу по статусу сервера и одновременно показывает количество серверов в каждом состоянии — так инженеры видят распределение состояния системы ещё до того, как начнут фильтрацию. Один элемент — две задачи: навигация и мгновенный обзор статуса.
Пользовательские графики
Графики сделаны под себя, и у них одна задача: обеспечивать видимость инцидентов. Инженеры быстрее всего реагируют на привычное, поэтому радикальная визуальная переделка дала бы обратный эффект по сравнению с тем, для чего нужны графики, — она бы замедлила реакцию во время инцидентов. Вместо редизайна я спросил инженеров, чего им не хватает.
Проблемой, о которой они снова и снова говорили, было отслеживание: как только курсор покидал элемент, фокус на расследуемом инциденте исчезал. Они не могли зацепиться за конкретную точку, одновременно считывая значения рядом. Я добавил постоянные горизонтальные и вертикальные направляющие линии с всплывающими подсказками, которые остаются на экране, чтобы точка фокуса оставалась закреплённой даже при перемещении курсора. Небольшое изменение, но оно сохранило то, что графики уже делали правильно: скорость.
Результаты
Это стало поворотным моментом: удалось убедить руководство уровня C согласовать давно назревшую масштабную переработку, после чего началась работа над дизайн-системой. Далее — визуальная хроника этой работы: единый внешний вид и ощущение, workflow обработки инцидентов, а также небольшие компоненты, которые выполняли непропорционально большую работу. Каждый экран отражает одно из описанных выше решений; вместе они формируют тот продукт, который мы видим сегодня.
Файл Figma