RU
EN
ноябрь 2022, апрель 2024 | new feature, information diagram
Оценка рисков для продукта по IT безопасности
Как я определила границы, наполнение и место новой функции в Netwrix 1Secure

Представьте, вы хотите продать услуги по IT-безопасности новому клиенту, и вам не составляет труда на первой встрече продемонстрировать ему список уязвимостей в его инфраструктуре, которые неплохо бы устранить. Именно для этой цели мы стали делать функцию оценки рисков в Netwrix 1Secure. Далее я подробно расскажу, что и как я делала, чтобы встроить эту фичу в уже существующий продукт.

Вводная

Что за продукт

Netwrix 1Secure монирит IT-системы. В режиме реального времени он отправляет уведомления о важных изменениях, помогая отслеживать подозрительные события и обеспечивать безопасность данных. Этот продукт специально разработан для нужд MSP (Managed Service Providers).

Кто его пользователи

MSP — IT-администраторы на аутсорсе. Они удалённо управляют IT-инфраструктурой клиентов, дополнительно предлагая услуги по безопасности.

Что им нужно

Функция оценки рисков поможет MSP лучше продавать услуги по безопасности. Её задача — быстро диагностировать состояние инфраструктуры организации, обнаружив ключевые риски, и показать, как это состояние меняется по мере того, как MSP эти риски устраняет.

Моя роль

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

Процесс работы

Чтобы решить эту задачу, я использовала подход, ориентированный на пользователя. Сначала я определила джоб стори и ключевые вопросы, на которые должен отвечать интерфейс, провела анализ похожих решений и наметила план встраивания фичи в продукт. После этого я перешла к итеративному процессу поиска дизайн-решения, которое отвечало бы на задачи и поставленные вопросы. Затем я собрала решение воедино, согласовала его с командой, внесла финальные правки и подготовила дизайн-спецификацию. Завершила процесс доработкой решения на основе полученной обратной связи.
Процесс в деталях

01 Define

Обозначаю потребности пользователей

Чтобы обозначить потребности пользователей, мы с продакт-менеджером сформировали джоб стори для этой фичи (job story, из теории Jobs-to-be-done). Как правило, она выражается формулой: Когда <Ситуация>, я хочу <Мотивация>, чтобы я мог <Ожидаемый результат>. Эти истории помогали мне проектировать решение, постоянно напоминая об истинных мотивах пользователей.
Продажа услуг безопасности
Когда я как MSP инженер нахожусь в процессе заключения сделки с клиентом, я хочу показать ему, какие проблемы есть в его системах, чтобы я мог допродать свои услуги по безопасности.
Демонстрация ценности услуги
Когда я как MSP инженер понизил уровень риска в системах клиента, я хочу продемонстрировать ему результаты проделанной работы, чтобы доказать ценность этой услуги.
Определяю ключевые вопросы
Затем, основываясь на этих стори и требованиях, я определила ключевые вопросы, на которые необходимо ответить с помощью основного интерфейса для этой функции:
  • Каков общий уровень риска для организации?
  • Насколько серьёзны риски для этой организации?
  • Почему эти риски критичны для организации?
  • Что вызывает этот риск?
  • Как текущие уровни риска сравниваются с предыдущими периодами?
  • Какая работа была проделана по сокращению рисков?
  • Какие пороговые значения используются для оценки рисков, и можно ли их изменить?
Изучаю другие решения
Я также изучила, как другие решения (конкурентов и похожих продуктов) показывают риски, чтобы понять:
  • Какую терминологию они используют для описания рисков
  • Как они определяют степень рисков
  • Какие визуальные элементы они используют для представления рисков

Планирую интеграцию функции

Я набросала информационную диаграмму, чтобы понять, как функция оценки рисков может интегрироваться в существующее приложение. Диаграмма помогла мне определить, какие части приложения могут быть затронуты, и не упустить важные моменты. Этот набросок стал основой для дальнейшей работы над дизайном.
Процесс в деталях

02 Ideate & Iterate

Перебираю варианты основного экрана рисков

Я начала с самого главного экрана — дашборда рисков. В начале поиска решения я всегда всё делаю на бумаге и только потом переношу варианты в Фигму. А когда есть дизайн-система, я миную этап lo-fi в цифре и собираю макеты из готовых блоков. В случае этого проекта было так же.

Итак, первая задача — ответить на вопросы: Каков общий уровень риска для организации? Насколько они серьёзны? И какая работа была проделана по сокращению этих рисков?
Итерация первая
Пытаясь ответить на эти вопросы, я сосредоточилась на «оценке рисков», или индексе, как это было указано в требованиях.

Работая над этой концепцией, я начала сомневаться в системе оценок. Хотя на первый взгляд она казалась разумной и простой, такие вопросы, как «Оценка 6 – это плохо или нормально? Подходит ли она для этого риска? Как рассчитывается общий уровень риска?» показывали, что всё сложнее, чем кажется.
Когда я поделилась сомнениями с продакт-менеджером, он согласился и рассказал, что у нас в компании был когда-то продукт, специализировавшийся на рисках, но его закрыли. Мы изучили отзывы пользователей по тому другому продукту, а также мнения инженеров поддержки и продаж. Стало ясно, что пользователи не понимали, как рассчитываются оценки, и наша команда тратила огромное количество времени на объяснения.

Эти отзывы подтвердили мои сомнения, и мы решили отказаться от системы оценок в пользу простоты.

Итерация вторая

  1. Я убрала индекс оценки рисков и заменила его простой классификацией: высокие, средние и низкие риски.
  2. Чтобы отслеживать изменения и ответить на вопрос «Как текущие уровни рисков сравниваются с прошлыми периодами?», я добавила виджеты трендов рисков. Они показывают рост или снижение рисков со временем, что позволяет быстро считать эффективность работы MSP.
  3. Серьезность рисков определяется четкими пороговыми значениями. Например, если найдено больше N сущностей, значит риск высокий.

Ищу решение для деталей риска

Подготовив версию дашборда и ответив на первые вопросы, я перешла к следующим: Почему эти риски важны для организации? Какие пороги используются для оценки рисков? Что вызывает этот риск?

Так, выбрав интересующий риск, вы переходите в его детали, которые раскрывают его суть:
  • Важность риска определяется его описанием и соответствующими нормативами безопасности.
  • Виджет тренда рассказывает историю, как менялся риск на протяжении времени, а также обозначает рамки пороговых значений.
  • Ниже виджетов идет список объектов, которые составляют этот риск.
К сожалению, из-за архитектуры приложения мы не могли разместить всю эту информацию на одном экране. Поэтому пришлось разделить его на боковую панель описания риска и отчет, который переехал в другую часть приложения – отчеты.

Прорабатываю профили рисков

И, наконец, какие пороговые значения используются для оценки рисков и могут ли они быть изменены?

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

03 Create

Объединяю всё вместе, чтобы интегрировать в приложение

Подготовив части решения, настало время объединить их все в одно целое. Чтобы помочь себе в этом и ничего не опустить, я превратила начальную информационную диаграмму в lo-fi схему, обозначив, где каждая часть данных о рисках будет находиться на экранах приложения.

Собираю прототип

Затем я собрала интерактивный прототип в Фигме, чтобы команда разработчиков в любой момент могла сама пробовать новую функцию и смотреть, как она вписывается в текущее решение.

Грумлю с командой и создаю дизайн-спецификацию

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

Провожу UX-ревью

В этой команде я была встроена в процесс Pull Request (PR), когда другой инженер проверяет код за своим коллегой. Моя задача – убедиться, что пользовательский интерфейс разработан правильно и соответствует макетам. Эта задача не была исключением.
Так, я оставляла комментарии на правку, а также могла рекомендовать изменения в CSS с помощью DevTools, чтобы подсказать разработчику, как можно точнее воспроизвести изначальный дизайн.
Процесс в деталях

04 Feedback

Получаем обратную связь после релиза

Благодаря регулярному общению с пользователями, продакт-менеджер собрал качественную обратную связь по выпущенному функционалу. Мы получили еще одно подтверждение его востребованности, несколько запросов и комментариев о том, что было не очень понятно.

Как выяснилось, у пользователей была проблема с понимаем виджета тренда, в частности разбивки на escalated и downgraded. Также они просили упростить показатели "до и после" и начинать список с недавно измененных рисков, поскольку они требуют более внимательного отношения.

Кроме обратной связи добавились новые требования:
  • Увеличение числа поддерживаемых рисков показало необходимость более эффективного поиска.
  • Нужна была возможность выгрузить отчет по рискам в качестве презентации.

Дорабатываю решение на основе новых данных

На основе полученной обратной связи и новых требований, я сделала следующие обновления:
  • Виджеты рисков: Тренд упрощен до простой линии и объединен со счетчиком рисков по категории критичности.
  • Список рисков: Переработан так, чтобы вся информация об изменениях риска была в одной колонке, и чтобы список был по умолчанию отсортирован по недавно измененным рискам.
Я также добавила новый вид для поиска по всем рискам с боковой панелью и быстрыми фильтрами. Он работает как фасетный поиск, позволяя пользователям быстро находить нужные метрики риска.
И наконец, я разработала презентацию в формате pptx, которую MSP могут экспортировать и демонстрировать клиенту вместо интерфейса продукта.

Итоги

Что было сделано

  1. Следуя дизайну, ориентированному на пользователя, я очертила цели и потребности MSP, а также обрисовала основные вопросы, на которые должен отвечать интерфейс новой функциональности. Я пронесла эти цели и вопросы через процесс итеративного проектирования и получила решение, которое им отвечает.
  2. Благодаря информационным схемам, диаграммам и интерактивному прототипу, я успешно интегрировала новую фичу в текущее приложение, обеспечив связанность взаимодействия и переходов.
  3. На протяжении всего процесса я тесно работала с командой разработки и менеджером продукта, синхронизируя с ними решение и дорабатывая его по возникающим вопросам и комментариям.
  4. Обратная связь от пользователей после релиза подтвердила принятые решение и дала почту для улучшений, которые я также спроектировала для последующего внедрения в приложение.

Что я бы сделала иначе

Я бы не ждала, пока пользователи увидят новый функционал только после релиза. Вместо этого я бы использовала макеты в Figma, чтобы протестировать решение раньше и дешевле получить первую обратную связь. Такой проактивный подход поможет увереннее выпускать новый фунционал и улучшения, да и в целом сделает дизайн-процесс эффективнее.
Смотрите также
AI и отчёты: Просто спроси систему
Как моя команда заняла первое место на AI-хакатоне Netwrix с идеей умных отчётов

Разработка дизайн-системы
Как я заложила основу для оптимизации проектирования 20+ продуктов компании Netwrix