Разработка интерфейса для корпоративного ПО - это всегда хрупкий компромисс между «сделать стильно» и «вывести на один экран тысячу критически важных параметров». Недавно наш отдел разработки взялся за полное переосмысление интерфейса в крупной системе учета лицензий и комплаенса. Причём тз было СЛИШКОМ лаконичным «Сделайте приятнее». И вот что я, как руководитель отдела и разраб (конечно обладающий какими-то эстетическими представлениями, но всё-таки к дизайнерам меня не отнесёшь), смог вынести:

СПЕЦИФИКА ПРОДУКТА Специфика таких продуктов не прощает ошибок. В потребительском приложении можно смело прятать функции в красивое гамбургер-меню ради минимализма. Но в B2B-софте уберешь кнопку с главного экрана - и у специалиста на другом конце провода встанет весь процесс аудита. Пользователи годами нарабатывают «мышечную память», и ломать её опасно. Наглядный пример из нашей же практики: наш руководитель сам активно пользуется этой системой. Когда мы перенесли меню кастомизации из неочевидного раздела общих настроек напрямую в блок дашборда (куда оно логически и относится), первую реакцию можно было описать коротко - он воспринял это в штыки. «Я три года нажимал туда, зачем вы мне всё сломали? Как мне теперь этим пользоваться?» И совершенно неважно, что новый путь стал интуитивно понятнее и экономит лишние клики. Это очень хорошо показывает, с чем сталкивается UX в корпоративном сегменте.

РЕШЕНИЕ После критики от начальства и моего однозначного ответа «Понял, переделаем», мы переосмыслили подход: -Фокус на сценариях, а не модулях. Вместо того чтобы вываливать списком все возможности системы, мы сгруппировали навигацию вокруг реальных задач специалиста. Выделили блоки управления документами, учета объектов и контроля статусов. -Управление вниманием. Вынесли все критичные триггеры на уровень дашборда. Если срок действия сертификата подходит к концу - интерфейс должен сам бить тревогу и вести пользователя в нужное место, а не заставлять его копаться в таблицах. -Перенос нагрузки на бэкенд. Чтобы обновленный и отзывчивый интерфейс летал, а не зависал при отрисовке сложных графиков, мы пересмотрели связку с базой данных. Вся тяжелая агрегация теперь происходит на бэкенде в PostgreSQL: мы оптимизировали запросы и настроили материализованные представления. В итоге наш React-клиент получает по API только готовую легкую выжимку метрик, а не пережевывает тысячи строк сырых данных на стороне браузера.

Главный инсайт, который я вынес из этого процесса: UX в сложном энтерпрайзе - это вообще не про красоту. Это инструмент радикального снижения когнитивной нагрузки. Пользователь должен открыть систему, за три секунды оценить статус по своим объектам и пойти пить чай, а не продираться сквозь дебри вложенных меню.

А как в ваших командах проходит редизайн сложных легаси-интерфейсов? Внедряете изменения плавно с долгим онбордингом или выкатываете новую версию рубильником для всех сразу?