Проектировал модуль сбора данных с новой архитектурой: ускорили сбор данных ×30

Продуктовый дизайнерИюль – Сентябрь 20255 человек в команде

Monq – all-in-one платформа наблюдаемости, мониторинга и автоматизации. Модуль «Сбор данных» принимает данные из различных источников и обрабатывает их для дальнейшего использования

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

Чтобы закрыть запросы рынка с запасом, модуль нужно было перестроить на уровне архитектуры. Так появились сборщики данных для приёма данных, а потоки сохранили функции обработки.

Моей задачей было перевести новую архитектуру в понятный интерфейс: показать связь между сборщиком и потоком, продумать состояния, действия и переходы между ними

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

В процессе уточнял технические ограничения у фронтендера и будущую логику у бекендера.

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

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

На User Flow разложил настройку по шагам: что пользователь делает в продукте и что настраивает в контуре компании.

Сборщик стал точкой входа в настройку сбора данных, поэтому создание потока я встроил в этот сценарий

Пользователь может запустить базовую связку сразу при создании сборщика, не переходя в другой раздел продукта.

Если настройка сложнее, он может сменить поток или перейти к его параметрам и донастроить обработку данных отдельно.

Поток остаётся важным для диагностики, даже когда пользователь работает со сборщиком

Если данные не приходят или приходят не в том объёме, пользователь сначала проверяет сборщик как точку входа.

Чтобы не заставлять его искать проблему в другом разделе, я показал ошибки и предупреждения потока рядом со сборщиком.

После создания сборщика пользователь продолжает сценарий в своей инфраструктуре, чтобы настроить передачу данных

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

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

Если пользователь заранее укажет метки агента, сборщик сможет подключиться к нему после установки

Заложил возможность заранее указать метку, которой ещё нет в системе. Когда пользователь создаст агента с такой меткой, сборщик подключится к нему автоматически

Собирал финальные макеты на верстку и проводил ревью: исправляли тултипы предупреждений и ошибок

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

+3.8%Подняли конверсию лендинг – лид. До релиза конверсия 0.2%, спустя месяц 0.4%.

×30Ускорили сбор данных – бизнес-задача релиза.

✦ Другие кейсы