UDV MultiProtect — трансформация legacy-продукта
Контекст и бизнес-задача
Необходимо было перенести ключевые возможности MultiProtect на новую платформу, сохранив основные сценарии работы с инцидентами и одновременно улучшив пользовательский опыт.
Основные задачи:
- Изучить существующее решение и выявить проблемы пользовательских сценариев.
- Определить совместно с командой функциональность, необходимую для MVP.
- Переработать список инцидентов и карточку инцидента.
- Упростить workflow обработки инцидентов и сократить количество лишних действий.
- Спроектировать интерфейс с учётом ограничений новой платформы.
- Подготовить решения к реализации и сопровождать разработку.
На весь цикл подготовки MVP было отведено три месяца.
Проблема
UDV MultiProtect — решение класса Incident Response Platform (IRP), предназначенное для работы с инцидентами информационной безопасности.
Изначально продукт работал на low-code платформе ePlat4m. Ограничения платформы, политические причины и оторванность от основной продуктовой линейки стали предпосылками для перехода на новую технологическую основу.
Это была не просто задача переноса существующего интерфейса. Требовалось переосмыслить пользовательские сценарии, определить необходимый функционал и создать основу самостоятельного продукта, который можно развивать дальше.
Я подключился к проекту на раннем этапе, когда нужно было сформировать MVP и подготовить его к реализации в условиях ограниченных сроков.
Я участвовал в формировании продуктовых решений, проработке требований, проектировании пользовательских сценариев и интерфейсов, а также сопровождал разработку до выпуска продукта.
Исследование и анализ
На старте я изучал существующий продукт, его сценарии, решения конкурентов и результаты пользовательских интервью.
Вместе с аналитиком и продактом мы определяли, какие функции действительно необходимы в первой версии, а какие можно отложить до последующих этапов развития.
Я предлагал варианты решений, разрабатывал wireframes и прототипы, перерабатывал пользовательские кейсы с учётом новой платформы.
Финальные решения о реализации принимались продактом.
Главный принцип: не переносить старую систему один в один, а использовать переход на новую платформу как возможность упростить взаимодействие с продуктом.
Pre-development Research
Проблемы старого интерфейса
В процессе анализа существующего решения выделились несколько проблем, которые усложняли работу с инцидентами.
- Перегруженная структура. Интерфейс был неадаптивным, рабочие области сильно растягивались, а информация распределялась по множеству вкладок и окон. Чтобы собрать полный контекст инцидента, пользователю приходилось переключаться между разделами.
- Сложный workflow. Процесс обработки включал множество шагов, подэкранов и статусов. Последовательность действий была недостаточно понятной.
- Избыточные действия. Для выполнения основных операций требовались дополнительные переходы по интерфейсу, что усложняло повседневную работу.
Продукт на старой платформе
Формирование MVP
Сроки не позволяли переносить весь функционал legacy-продукта в первой версии. Вместе с командой мы сфокусировались на основных сценариях реагирования и обработки инцидентов.
В MVP вошли:
- Новый список инцидентов.
- Переработанная карточка инцидента с расширенным набором данных.
- Основные сценарии реагирования и обработки инцидента.
- Более понятная структура информации и workflow.
При этом мы не стали разрабатывать заново всё базовые механизмы, необходимые для работы продукта. Для стандартных функций — таких как управление активами, ролевая модель, авторизация и другие системные возможности — использовалась функциональность новой платформы.
Это позволило сосредоточить основные усилия на специфических сценариях IRP-продукта и улучшении пользовательского опыта.
За пределами MVP остались сложная ролевая модель, система отчётов, полноценная система учёта активов и система планирования реагирования на инциденты. При этом базовые возможности платформы, необходимые для работы с активами, ролями и авторизацией, использовались в рамках её существующего функционала.
Такое разделение позволило определить границы MVP, избежать дублирования базовых возможностей платформы и выполнить заявленные требования в рамках трёх месяцев.
Ключевое UX-решение: новая карточка инцидента
Главным объектом переработки стала карточка инцидента — рабочее пространство, в котором аналитик получает информацию об инциденте и выполняет основные действия по его обработке.
В старом интерфейсе информация была распределена по вкладкам и большим формам. В новой версии я перестроил структуру вокруг основного рабочего сценария: ключевой контекст, связанные данные и действия получили более понятное расположение.
До
- Большие формы с множеством полей.
- Информация распределена по вкладкам.
- Необходимость переходить между разделами.
- Сложный процесс работы с инцидентом.
Карточка инцидента на старой платформе
После
- Ключевая информация собрана в едином рабочем пространстве.
- Данные об инциденте организованы по смысловым блокам.
- Характеристики и основные действия вынесены в отдельные области.
- Вспомогательные материалы отделены от основного сценария.
Новая карточка инцидента
Как изменилась структура
Центральная область — основной контекст. Здесь собрана информация об инциденте, атакованном и атакующем, методиках и событиях.
Боковой блок — характеристики. Совместно с аналитиком мы определили приоритетные поля, которые должны быть доступны при работе с инцидентом.
Область основных действий — управление workflow. Действия, связанные с переходом между этапами обработки, получили более заметное и доступное расположение.
Отдельные вкладки — вспомогательная информация. Плейбуки, документы, заключение и история изменений отделены от основного сценария.
В результате карточка стала более структурированной: пользователю проще ориентироваться в данных и находить нужные действия.
Упрощение workflow
Отдельной задачей стало переосмысление состояний инцидента.
В старом решении процесс включал множество статусов и сложных переходов. В новой версии мы оставили четыре состояния:
- Новый инцидент.
- В работе.
- Закрытый. Устранен.
- Закрытый. Ложный.
Основную информацию, которая раньше была распределена по двум экранам с пятью вкладками на каждом, удалось разместить на одном экране.
Это сократило необходимость переключаться между разделами и позволило сделать основной рабочий сценарий компактнее.
Проектирование шло итерационно — от изучения существующего решения и формирования сценариев до прототипов и готовых макетов.
В процессе работы:
- Обсуждал макеты с аналитиком и продактом.
- Сверял решения с пользовательскими интервью.
- Проводил демонстрации и собирал обратную связь.
- Тестировал прототипы на пользователях.
- Обсуждал технические ограничения с разработчиками.
- Уточнял требования и сопровождал реализацию.
- Проверял готовый интерфейс и участвовал в корректировках.
Моя работа не ограничивалась подготовкой макетов. Я участвовал в обсуждении продуктовых решений и сопровождал их на протяжении всего цикла — от идеи до реализованного интерфейса.
Результаты
Упрощение работы с инцидентами
Количество кликов при обработке одного инцидента сократилось минимум на 10. Ключевая информация была собрана в едином рабочем пространстве, а основной workflow стал компактнее.
Выпуск MVP
Пилотирование
Основа для дальнейшего развития
Итог
Этот проект стал для меня опытом трансформации сложного B2B-продукта, в котором дизайн был частью продуктовой работы, а не только визуальным оформлением.
Я участвовал в определении состава MVP, предлагал решения, переосмысливал пользовательские сценарии и проектировал новую структуру интерфейса. Вместе с командой мы смогли отказаться от прямого копирования legacy-решения, сосредоточиться на основных задачах пользователей и подготовить продукт к запуску в ограниченные сроки.
Главный результат моей работы — более понятная структура карточки инцидента и упрощённый workflow, реализованные в выпущенном MVP.