Слишком много событий
Пользователь тратит силы не на разбор проблемы, а на то, чтобы отсечь лишнее и собрать картину руками.
Helix SOC — платформа для разбора инцидентов без лишнего шума
В этом кейсе я показал, как можно собрать разрозненные сигналы в понятный workflow: от очереди инцидентов до быстрого решения, эскалации и контроля команды.
В этом концепте я собрал enterprise-платформу для разбора инцидентов: с очередью, карточкой кейса, графом сущностей и action surface рядом с причиной. Основная идея решения — не просто показывать alerts, а быстро собирать контекст и помогать команде переходить к действию без лишних переходов между экранами.
Роль
Lead designer: структура продукта, ключевой сценарий, экраны и визуальный язык.
Фокус
Приоритизация, контекст, быстрые действия и понятная работа с очередью инцидентов.
Результат
Система стала читаться как цельный инструмент, а не как набор разрозненных событий.
Incident-first workflow
Один кейс вместо россыпи сигналов
Очередь, причина, confidence и affected assets собираются в один фокусный кадр.
Action surface
Контекст и действия рядом
Быстрые шаги остаются в том же слое, где читается история инцидента и уровень риска.
Проблема
Во многих сложных системах пользователь сначала видит слишком много сигналов, а уже потом пытается понять, что из этого действительно важно
Из-за этого теряется фокус: alerts приходят пачками, контекст размазан по разным местам, а нужное действие находится не рядом с причиной, а где-то глубже по интерфейсу. В результате даже сильный инструмент начинает восприниматься как шумный и тяжёлый.
Контекст разбит
Сущности, история, уровень риска и действия живут в разных частях продукта и не складываются в цельный сценарий.
Решение принимается дольше
Даже когда инцидент понятен, путь до действия остаётся длинным: нужно проверить несколько экранов и ничего не потерять по дороге.
Подход
Концепт я собрал через открытые материалы, разбор security workflow и анализ публичных интерфейсных паттернов
Основа решения — desk research и сценарный анализ. Я смотрел, как в security-продуктах подают очередь инцидентов, карточку кейса, граф связей и быстрые действия, а затем собрал более спокойный и читаемый workflow вокруг инцидента как главной единицы работы.
Роль
Собрал структуру экрана, определил основную точку входа, разложил приоритеты по уровням и выбрал, какие действия должны быть доступны сразу, а какие — только после чтения контекста.
Опора для решений
Публичные материалы по security workflow, паттерны data-heavy интерфейсов и логика рабочего сценария: увидеть проблему, понять влияние, принять решение и не потерять контекст по дороге.
Что я смотрел и откуда взял решения
Перед визуальной сборкой я посмотрел, как похожие задачи решаются в реальных security-платформах
Ниже — несколько публичных интерфейсов, на которые я ориентировался. Смотрел не только на визуал, но и на то, как устроены обзорные экраны, incident review, investigation graph и подача контекста в одном рабочем слое.
Что взял из overview-экрана
Понравилось, как обзор собирается из крупных блоков: инциденты, автоматизация, аналитика и data connectors. Из этого я взял идею крупного hero-слоя и спокойную компоновку виджетов без визуального шума.
Что взял в сценарий расследования
Отсюда я опирался на сам принцип investigation graph: связи между сущностями должны не украшать экран, а объяснять, почему система собрала события в один инцидент и где искать следующую зацепку.
Что понравилось в case view
Здесь был полезен сам формат case management: единая точка работы, редактируемые поля, статус, владелец и действия в одном месте. Из этой логики я собрал свой action surface и decision block рядом с кейсом.
Решение
Я построил интерфейс вокруг инцидента, а не вокруг бесконечного потока сигналов
Вместо модели, где пользователь сначала получает десятки разрозненных событий, а потом пытается связать их вручную, я собрал единый workflow: очередь инцидентов, карточка с ключевым контекстом, связи между сущностями и быстрые действия рядом с причиной. Так инструмент начинает помогать принимать решение, а не просто уведомлять о проблеме.
1. Приоритет читается сразу
Уровень риска, свежесть события и краткая суть инцидента вынесены на первый экран, чтобы внимание сразу уходило туда, где реально нужна реакция.
2. Контекст собран рядом
Пользователю не нужно открывать пять разных экранов, чтобы понять, кто затронут, откуда пришёл сигнал и что именно выглядит подозрительно.
3. Действие не оторвано от причины
Ключевые шаги вроде эскалации, изоляции устройства или назначения владельца доступны прямо внутри сценария, а не спрятаны глубоко в меню.
От wireframe к финальному UI
Для трёх ключевых сценариев я собрал один и тот же путь: wireframe → low-fi прототип → финальный UI
Сначала я проверял состав блоков и иерархию. Затем собирал low-fi слой, чтобы увидеть экран уже как рабочий desktop-интерфейс. После этого доводил сценарий до более цельной визуальной системы с акцентами, статусами и сильной UI-подачей.
На этом экране я проверял, читается ли приоритет с первого взгляда и видно ли, куда команде смотреть в первую очередь. В финальном слое очередь стала более цельной: с уверенным статусом, confidence и коротким summary по каждому кейсу.
Wireframe
Состав блоков
Low-fi прототип
Проверка иерархии
AllCriticalAssignedNew
critical91% confidence
Подозрительный вход → повышение прав → выгрузка данных
5 минут назад · finance-vault · владелец не назначен
high74% confidence
Сервисный аккаунт получил нетипичные права
12 минут назад · проверка без эскалации
medium61% confidence
Вход из нового региона без подтверждения устройства
19 минут назад · новый кейс
Финальный UI
Visual polish
Во втором сценарии я собирал историю проблемы в одном месте: summary, affected assets, evidence и причина, по которой кейс поднят в critical. Финальный слой сделал этот экран более уверенным и читаемым.
WireframeСостав экрана
Low-fi прототипКонтекст без лишних переходов
critical91% confidence
Подозрительный вход, затем повышение прав и копирование чувствительных файлов
user · payroll-admindevice · win-214service · finance-vault
Первое событие · 09:14Владелец · не назначенРиск · очень высокий
Почему кейс поднят
Необычный IP и новое устройствоПовышение прав в течение 3 минутПопытка выгрузки файлов из чувствительного сегмента
Что затронуто
finance-vaultpayroll scopeservice session key
Финальный UIVisual polish
Третий сценарий отвечает за переход к действию. Здесь важно было не потерять связку между причиной, таймлайном, владельцем и следующими шагами — поэтому action surface живёт рядом с evidence и escalation.
WireframeЛогика действий
Low-fi прототипAction surface
РешениеГотово к действию
Что можно сделать сразу
Краткая рекомендация
Сначала заблокировать активную сессию, затем передать кейс владельцу домена и проверить объём копирования данных.
Timeline
09:14 · вход с нового IP09:17 · повышение прав09:19 · попытка копирования09:21 · инцидент поднят в critical
Эскалация
Владелец · SOC leadДомен · FinanceВлияние · Sensitive data
Финальный UIVisual polish
Одна система на трёх уровнях детализации
Во всех сценариях я держал один и тот же принцип: сначала быстро считать риск, затем понять причину и только после этого перейти к действию. За счёт этого и wireframe, и low-fi, и финальный UI остаются частью одной системы, а не набором разрозненных экранов.
Ещё экраны системы
После проработки ключевых сценариев я собрал из них цельную desktop-систему с несколькими связанными экранами
Очередь инцидентов
Обзор смены
CRITICAL · Выгрузка данных после подозрительного входа
5 минут назад · confidence 91% · владелец не назначен
HIGH · Резкий скачок прав у сервисного аккаунта
12 минут назад · confidence 74% · ждёт проверки
MEDIUM · Необычный вход из нового региона
19 минут назад · confidence 61% · без эскалации
LOW · Необычное время активности у подрядчика
32 минуты назад · confidence 38%
Очередь инцидентов
Первый экран помогает быстро понять, что действительно требует внимания прямо сейчас. Здесь важна не плотность данных сама по себе, а хорошая иерархия: риск, суть, время, confidence и статус владельца.
Карточка инцидента
Карточка инцидента
Краткое резюме
Подозрительный вход → повышение прав → копирование чувствительных файлов
Затронуто: payroll-admin, win-214, finance-vault
Confidence: 91% · Severity: critical
Что видно сразу
Сигналы собраны в одну историю
Есть краткая причина риска
Не нужно искать контекст вручную
Карточка инцидента
Здесь я собрал основную историю проблемы в одном месте. Пользователь быстро считывает, что произошло, кого это касается, насколько риск высокий и почему система считает этот кейс важным.
Граф сущностей
Связи и влияние
Связанные сущности
user · payroll-admin
device · win-214
service · finance-vault
token · new-session-key
Граф сущностей
Он помогает быстро увидеть, как между собой связаны пользователь, устройство, сервис и подозрительное действие. Такой экран особенно хорошо показывает системное мышление и работу со сложной связанной информацией.
Центр действий
Решение и эскалация
Быстрые действия
Изолировать
Эскалация
Назначить
Все ключевые действия доступны прямо в контексте инцидента
Timeline
09:14 · вход с нового IP
09:17 · повышение прав
09:19 · попытка копирования данных
09:21 · инцидент собран и поднят в critical
Центр действий
Одна из ключевых идей кейса — не отрывать действие от причины. Поэтому важные шаги находятся рядом с таймлайном и контекстом, а не в отдельном глубоком сценарии.
Финальный UI / hero screens
Крупные hero-экраны собирают систему в более цельную product-подачу
Здесь я намеренно ушёл в более крупную и выразительную подачу: сильнее масштаб, больше воздуха, световые акценты и меньше дробления на мелкие карточки. Этот слой нужен, чтобы кейс показывал не только логику, но и зрелый visual execution.
screen 01
Incident Queue Hero
Крупный экран очереди с явной приоритизацией. Здесь считывается ритм всей системы: severity, confidence, краткая история кейса и спокойная dark-first подача без перегруза.
screen 02
Incident Overview
Этот экран собирает summary, граф связей и decision block в один слой. Пользователь видит историю инцидента, причины, affected assets и следующие шаги без прыжков по интерфейсу.
Ключевые решения
Основные решения, на которых держится вся система
Incident-first
Главная единица интерфейса — не отдельный alert, а уже собранный кейс. Это резко снижает шум и помогает быстрее увидеть действительно опасную ситуацию.
Контекст в одном слое
Причина, affected assets, таймлайн, confidence и граф связей живут рядом. Пользователю не нужно собирать историю вручную по нескольким экранам.
Действие рядом с доказательствами
Изоляция, эскалация и назначение владельца находятся там же, где читается инцидент. За счёт этого интерфейс помогает принимать решение, а не просто сообщает о событии.
Результат
В итоге получился интерфейс, который помогает быстрее понять ситуацию, не терять контекст и увереннее переходить к действию
Сигналы стали читаться спокойнее
Пользователь видит не россыпь событий, а собранный инцидент с понятным уровнем важности и кратким объяснением, почему он требует внимания.
Контекст и действия собраны рядом
Не нужно держать в голове много экранов и перепрыгивать между ними. История инцидента, связи и быстрые шаги находятся в одном сценарии.
Продукт воспринимается цельнее
Интерфейс начинает работать как понятный рабочий инструмент для команды, а не как набор сложных виджетов и статусов без единого центра тяжести.
Куда можно развить продукт
