ESB

Интеграционная шина данных для крупного корпоративного клиента (под NDA). Шина обменивает данные между десятками внутренних систем — генераторами и потребителями. Пользователи — backend-инженеры и интеграционные архитекторы.

Задача:
Спроектировать UI для двух ключевых сценариев: настройки маршрутов передачи данных и аудита проходящего трафика. Без потери глубины настройки, доступной в legacy CLI.

Что я делал:

• Провёл интервью с backend-инженерами и SRE — выяснил, что им важна возможность вставлять кастомные скрипты прямо в маршруты, а не только конфигурировать через визуальный редактор
• Спроектировал гибридный интерфейс: визуальная схема + встроенный редактор кода для тех узлов, где визуальной логики недостаточно
• Для аудита разработал интерфейс с многоуровневой фильтрацией: пользователи привыкли к sql-подобным выражениям, заменил их визуальным конструктором с сохранением выражения внизу для копирования

Урок:
Когда проектируешь интерфейс для разработчиков, не пытайся «упростить» — дай им контроль того уровня, к которому они привыкли. Идеальный UI для них — это не «нет кода», а «можно код, если хочется».

Метрики и результат:
NDA

Думаю, если вы здесь находитесь, то вы знаете для чего нужна шина данных, но чтобы уточнить. Шина позволяет обмениваться данными разным сервисам. В нашем случае, между бесконечным количеством «генераторов данных» и «системы валидации трафика».

Этот экран настройки маршрутов, один из основных. Backend-инженеры настраивают маршруты передачи данных между системами

Аудит — это как раз со стороны «системы валидации трафика». Из забавного настройка фильтра справа. На других проекта лейауты пришли к общему знаменателю,
но Шина из-за сложности самого продукта отстает в этом плане.

Для backend-инженеров возможность вставлять кастомный код в маршрут — не "лишняя сложность", а ожидаемая базовая функция.