Дизайн интерфейса платформы кибер­безопасности

Сделали полный редизайн платформы для информационной безопасности, а еще спроектировали с нуля конструкторы отдельных процессов этой системы. И уложились в 6 месяцев. Сами не поняли, как это сделали, но потом разобрались и написали кейс. Вот он.

Платформа «Радар» — узкоспециализированный комплекс для информационной безопасности. Он собирает внутри себя огромное количество данных от компьютеров и ПО, которые находятся внутри корпоративной сети, помогает специалистам по безопасности выявлять угрозы (сетевые атаки, вирусы и все, что может угрожать данным) и анализировать эту информацию.

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

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

Для самых матерых безопасников многие из этих проблем проблемами не являются — они уже привыкли. Но в перспективе продуктом будут пользоваться и менее опытные специалисты. Нужно было создать удобную версию для пользователей с разным уровнем владения платформой и знаний о предметной области.

Еще важно было сделать новый интерфейс более «продажным»: симпатичным и аккуратным.

Поэтому мы сформулировали наши задачи так:

За шесть месяцев мы перепроектировали весь сервис. Для этого мы:

Три инструмента-«конструктора» внутри продукта были спроектированы с нуля.

Остальное было переработано в соответствии с задачами пользователей и текущих (а иногда и будущих) возможностей системы.

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

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

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

Объем информации, который мы получили, был настолько большой, что в какой-то момент к ее анализу подключилась вся команда «Собаки», даже те, кто не участвовал в проекте.

В итоге мы выделили трех пользователей:

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

Все возможности сервиса мы условно разделили на три части.

Учли и то, что часто все эти роли принадлежат одному человеку, поэтому от идеи делить сервис по функционалу отказались сразу. Он скорее обрастал возможностями в процессе.

В таком порядке и проектировали.

Первая и третья часть уложились в 4–5 недельных итераций.

Остальное было переработано в соответствии с задачами пользователей и текущих (а иногда и будущих) возможностей системы.

Поэтому каждый конструктор — правил корреляции, разбора и нормализации, отчетов — мы проектировали отдельно, также разбив на 4–5 итераций. Иногда созванивались с заказчиком и внутри итераций, чтобы на ходу проверить гипотезы: в сложных проектах легко начать фантазировать в отрыве от реальности.

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

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

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

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

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

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

Приятное удивление от того как быстро вы разобрались в смысле нашего продукта и предложили визуально привлекательное решение по полной переработке интерфейса. Организационные процессы также оставили приятное впечатление, наглядный роадмап, шаблоны в фигме, презентации наработок, всё просто и понятно.

Вы проделали колоссальную и бесценную работу, которой мы в целом остались очень довольны. Я не думаю, что в нашем случае можно было сделать что-то большее.

Михаил Левин, руководитель проекта

Наталья Прокофьева, директор «Собаки Павловой»

Красивый кейс можно посмотреть на нашем сайте. А еще можно подписаться на наш телеграм-канал Собака лает.