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

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

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

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

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

1. Провести исследование пользователей и сценариев использования ими платформы. 2. 2. Перепроектировать интерфейсы платформы в новой визуальной стилистике, учитывая задачи и подготовку «пользователей-неспециалистов».

3. Передать в разработку макеты с описанием структуры и логики интерфейса

Какой результат?

За шесть месяцев мы перепроектировали весь сервис

Для этого мы:

- Погрузились в предметную область

- Поговорили с пользователями (как этой платформы, так и других систем такого класса)

- Собрали мудборд со стилевыми решениями и разные концепции того, как может строиться интерфейс

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

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

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

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

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

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

Здесь мы раскладываем задачи по пользователям

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

- Оператор

- Аналитик

- Администратор

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

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

- Операционная деятельность

- Конструкторы правил и инструменты аналитика

- Администрирование платформы

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

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

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

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

Один из новых конструкторов — для правил корреляции

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

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

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

Так «под капотом» выглядит интерактивный прототип, который мы тестировали (точнее, его маленькая часть)

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

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

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

Атомарные компоненты, из которых состоит интерфейс

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

160 экранов системы (не считали состояния и вспомогательные интерфейсы), которые собраны в интерактивный кликабельный прототип.

Библиотека компонентов (от кнопок до целых блоков), из которых строятся интерфейсы.

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

22 итерации проектирования

4 дизайнера

350+ макетов в Figma

34 часа обсуждений с командой заказчика