Большинство энтерпрайз‑интерфейсов выглядят так, будто их верстали в 2003 году под дулом пистолета. Хотя кто знает, может это не так уж далеко от правды… Знакомая картина: вы открываете панель управления инфраструктурой, где нас встречает таблица на 40 колонок с горизонтальной прокруткой, пачка модальных окон, перекрывающих друг друга, и кнопка «Сохранить», клик по которой может случайно положить сетку целого филиала.
В продуктовом B2B‑дизайне, когда речь идет про IaaS, СХД или управление флотом ПК, мы боимся не за условный ретеншен, а за то что сотня серверов одномоментно ляжет. Исходя из этого, важно серьезнее отнестись к Error Prevention. Наш юзер не просто меняет картриджи, это инженер инфраструктуры. А значит мы не можем ограничиться удобством для пользователя с условными Call to Action. Инфраструктура должна быть превентивной, а не просто комфортной.
Недавно передо мной как раз встала задача: спроектировать веб‑панель мониторинга и планировщик задач для парка из 10 000+ устройств. Я еще не начала, но уже устала. Так как до того, как открывать фигму, пришлось перелопатить добрый десяток Best Practice и паттернов, расщепив их на атомы, молекулы и сценарии. Аналоги вроде Microsoft Endpoint Manager и VMmanager были декомпозированы. В общем, все по классике.
Главный босс — вьюпорт 1280×800
Мы привыкли рисовать макеты на 1920px. Те, что скромнее, на классический десктоп из 1440px, раздавая компонентам царские отступы и воздуха побольше да побольше, все как завещали предки. Но в реальности дежурный админ в ЦОД часто сидит с 13-дюймового ноутбука.
Вычитаем системную панель Google Chrome, адресную строку браузера, вкладки, и у нас остается жалкие ≈630px полезной высоты. В эту область нужно уместить дашборды здоровья системы, фильтры, таблицу мониторинга и панель управления. Желательно чтобы иерархия масштабов сохранялась и глаз админа радовался.
Методы борьбы за разумное доброе вечное:
1. Для начала решено было оптимизировать сайдбар. Вместо него выбрала компактный Navigation Rail. Правда при брейкпоинте на 1920px он послушно раскрывается обратно.
2. Collapse фильтров. Левая панель фильтрации, незаменимая для сегментации и сортировки вещь, но важно было сделать ее гибкой. Поэтому оставила возможность ее свернуть. Чтобы дать пользователю шанс прочитать полное название файлов.
3. Отказалась от табов и свитчеров в рамках создания задачи. Если у вас 3 типовых правила, табы могли бы сработать. Но одной из ключевых точек развития было масштабирование концепции, поэтому я выбрала старые добрые селекты. Если завтра бэкенд выкатит еще 30 фич, от смены паролей до чистки кэша, интерфейс переживет это. Селекты здорово экономят пространство убирая лишний скролл. В них можно положить множество опций для автоматизации процессов и не потерять ни один лишний пиксель.
4. Математическая сетка вместо колонок. Вся система построена на жесткой микро‑сетке с шагом в 8px. Отступы продиктованы функцией, а не эстетикой. Плотность таблицы и панелей оптимизировалась под количество элементов, которые администратор должен видеть без лишнего скролла.
Битва с модальным хаосом или Layered Drawers против модалки
Представим юзкейс, админу нужно настроить сложный бэкап и выбрать 500 конкретных серверов из 10 000.
В легаси‑системах это частенько работает через модальные окна одно поверх другого. Паттерн сомнительный, ну окей. Вам нужно подсмотреть ID упавшего сервера в таблице на фоне... но вы не можете, потому что модалки заблокировали экран. Вы кликаете мимо, попап закрывается, прогресс слетает. Неудобно получилось.
Второй вариант отдельное окно. Нас уводят дальше от смыслов, оставляя дорожку из хлебных крошек как на старых добрых многостраничных сайтах. Если данных действительно много, то вариант хороший, но хотелось попробовать что‑то лучше.
Решила обратиться к дроверу, так как он позволяет не терять контекст происходящего. Но вызов выбора устройств поверх задачи снова создавал конфликт окон. Модалка поверх дровера не выглядит изящным решением. Сменяющаяся информация в одном и том же дровере может запутать пользователя. По форме правильно, по существу, издевательство.
Но что может быть лучше дровера? Правильно, дровер поверх дровера. Статья на Medium от Mohsen Hosseinian подкинула мне эту идею. Ребята протестировали Layered Drawers, и он показал хорошие результаты в сценариях последовательного перехода между задачами.
Моя гипотеза состояла в том, что многослойная шторка позволяет сохранить контекст. А шторка сама по себе сохраняет часть экрана видимой, поэтому пользователь может подсматривать в уже созданные правила.
Layered Drawers идет как дополнение к аддитивному смарт‑поиску. Если админу не хватило поиска по маскам и тегам и его полномочия тут все, иногда приходится докликать себе еще немного ПК через ручной выбор устройств. И тут на сцену выходит наш Layered Drawers. Фоновые клики блокируются затемнением. Иерархия не ломается, контекст сохранен. Мы избегаем комплекта из модальных окон одно поверх другого, которые вылетают на нас как зараженный трояном Windows XP.
Такая вот коллизия
С окнами разобрались. Но главная беда в инфраструктуре — это коллизии. Дизайн должен быть превентивным, поэтому я разделила коллизии на два типа:
Логические, когда мы очень хотим, но не можем поставить 2 задачи на одну дату. И Ресурсные, когда мы хотим и можем, но тогда вся сеть ляжет.
Способы как мы с этим будем бороться:
Индикация ошибки прямо в бейджах строк таблицы. Сразу видно задачи с черной меткой и необходимостью их пофиксить. Можно даже сделать сортировку по задачам с ошибками.
При создании задачи есть обязательный блок «Действия при сбое». Что делать системе, если на первых 5 ПК обновление BIOS выдало ошибку? Продолжить и получить 10 000 «кирпичей»? Хорошая идея, но оставим ее для интерфейсов, которые не думают про Error Prevention.
Выводим название ошибки в карточку задачи. Желательно еще и прикрутить к нему Call to Action. Чтобы не отходя от кассы все быстренько исправить.
Таймлайн, для пущей наглядности. Это агрегированная визуализация плотности. Админ видит пиковые нагрузки. Если столбик пробивает красную ватерлинию, значит ресурсов не хватит, канал больше задач не тянет. Клик по красному слоту вызывает шторку Master‑Detail, где конфликтную задачу можно сдвинуть на свободный слот. Предполагаю, что визуализация плотности задач через такую тепловую карту сократит количество ресурсных коллизий и сделает их более управляемыми.
Гипотезы, метрики и здравый смысл
Высокая плотность данных делает интерфейс визуально перегруженным для неподготовленного человека. Хоть наш пользователь подготовлен и много чего повидал, моя задача была сделать его опыт взаимодействия комфортным и предсказуемым.
Сделав ставку на компактные интерфейсные решения, многослойные шторки, аддитивный поиск и защиту от коллизий, я заложила базу для MVP. Ожидаемый эффект, который мы будем замерять на юзабилити‑тестах:
Снижение Time‑on‑Task: массовые операции выполняются за пару кликов с помощью масок поиска, без долгого пролистывания бесконечных списков. Многие действия автоматизируются с помощью дополнительных опций выбора, уже на этапе создания правила.
Снижение Error Rate: превентивная валидация коллизий и отсутствие слепых зон.
А теперь вопрос к коллегам в комментариях:
Как вы в своих B2B и админских продуктах решаете проблему многоуровневого выбора и сохранения контекста? Уходите в бесконечные табы, открываете новые страницы с хлебными крошками или, может, вообще оставляете админам старую добрую консоль? Делитесь болью).
