{"id":14279,"url":"\/distributions\/14279\/click?bit=1&hash=4408d97a995353c62a7353088166cda4ded361bf29df096e086ea0bbb9c1b2fc","title":"\u0427\u0442\u043e \u0432\u044b\u0431\u0435\u0440\u0435\u0442\u0435: \u0432\u044b\u0435\u0445\u0430\u0442\u044c \u043f\u043e\u0437\u0436\u0435 \u0438\u043b\u0438 \u0437\u0430\u0435\u0445\u0430\u0442\u044c \u0440\u0430\u043d\u044c\u0448\u0435?","buttonText":"","imageUuid":""}

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

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

Что такое Пангео Радар?

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

Что нужно было сделать?

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

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

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

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

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

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

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

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

  1. Погрузились в предметную область
  2. Поговорили с пользователями (как этой платформы, так и других систем такого класса)
  3. Собрали мудборд со стилевыми решениями и разные концепции того, как может строиться интерфейс

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

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

Основное. Инциденты
Основное. События 
Основное. Активы

Итог

  • 160 экранов системы(не считали состояния и вспомогательные интерфейсы), которые собраны в интерактивный кликабельный прототип
  • Библиотека компонентов (от кнопок до целых блоков), из которых строятся интерфейсы
  • Принципы построения макетов и правила их адаптации, которые помогут заказчику самостоятельно развивать продукт в будущем
  • 22 итерации проектирования
  • 34 часа обсуждений с командой заказчика
  • 350+ макетов в Figma

Как все происходило?

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

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

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

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

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

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

  • Оператор
  • Аналитик
  • Администратор

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

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

  • Операционная деятельность
  • Конструкторы правил и инструменты аналитика
  • Администрирование платформы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что говорит заказчик?

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

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

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

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

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

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

0
32 комментария
Написать комментарий...
Сообщество WSA.vc
Ответить
Развернуть ветку
Анна Богданова

вы делаете конкуренцию Вадиму) он все время сокращает статьи ))

Ответить
Развернуть ветку
Сообщество WSA.vc

Трудно конкурировать с AI )

Ответить
Развернуть ветку
Вадим Д.

Ученик никогда не станет лучше учителя (-:
Сокращаю по-взрослому:

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

Ответить
Развернуть ветку
Алексей в

Давай в рифму

Ответить
Развернуть ветку
chmonka

Небольшое краткое содержание, если не успел подготовиться к пересказу в школе.

Ответить
Развернуть ветку
Nitreed1

А о чем статья? А то не понял, можно ещё раз :)

Ответить
Развернуть ветку
Mikhail Chivi (RainRock)

а скиньте пожалуйста ссылку на инструмент :)

Ответить
Развернуть ветку
Mike Ivanovich

Бль, 360 макетов ..и это не предел ведь, да? Количество не равно качеству, и дизайн это рудимент, реквестирую статью где архитектор данных катал разные темы пол года, и смотрел какие интерфейсы интеграции данных выделить в ядровые, как архитектуру данных реализовать, как это бодро разрабатывать, ведь 22 итерации за 180 дней это тоска, плавная нота, почти коричневая. Интерфейс вторичен, мягко говоря. Вы подумайте если завтра заказчик решит что пора уже использовать ттс и стт , ваше выражение лица?
Резюмирую, вы показали в этой статье тоску и серые будни, инновационные проекты, в т ч в этом домене , делают иначе, уже 23 год, а не 1997.
Если вам интересно как стать крутым, бодрым, быть готовым к вызовов завтрашнего дня - пишите в лс, первая консультация бесплатно

Ответить
Развернуть ветку
Elena Pliner

Это сейчас было очень смешно :)

Ответить
Развернуть ветку
Mike Ivanovich

Так вот, цифры ваши, они вас смешат?)) или вас смешит мой тезис по ттс и стт? Или что вы черепахи по итерации в неделю? Ну правда, вкиньте что вас смешит, поржем вместе , если это не на нервной почве

Ответить
Развернуть ветку
Elena Pliner

Все смешно в вашем посте, абсолютно все :)

Ответить
Развернуть ветку
Mike Ivanovich

Лайк!

Ответить
Развернуть ветку
Юрий

Не очень ясно про "По ходу работы мы собирали библиотеку компонентов", она мало чем отличается от готовой беспл. библиотеки vuetifyjs (https://vuetify.cn). В целом субъективно UI выглядит устаревшим

Ответить
Развернуть ветку
Elena Pliner

тут больше про ux история. Собака этим сильна

Ответить
Развернуть ветку
Yana Perovic

вот бы еще подтверждение увидеть, в статье ничего об этом нет.

например:
- Скорость выполнения операции X увеличилась на X
- количество ошибок X снизилось на X
- новые сотрудники осваивают UI за неделю, а раньше нужно было 3 недели. вот как мы это поняли: 1,2,3

Благодарный отзыв заказчика - не подтверждение. Это метрика успешности работы студии, которая получает деньги за ок от заказчика. Но причем тут UX?

Опросы в процессе проектирования, тоже не подтверждение. Это способ найти инсайты, с которыми потом можно что-то сделать

Как то, что они проделали, повлияло на - UX вопрос открытый.

Ответить
Развернуть ветку
Mike Ivanovich

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

Ответить
Развернуть ветку
Mike Ivanovich

Сорри, не в ту ветку, но вы поняли.

Ответить
Развернуть ветку
Elena Pliner

нет, я вас точно не пойму, зачем мне ваше словоблудие))

Ответить
Развернуть ветку
Mike Ivanovich

Да я из последних сил спасаю ваш топик на который все в два слоя положили, а вы не цените((

Ответить
Развернуть ветку
Elena Pliner

По-моему, вы совсем запутались. Это не мой топик ))

Ответить
Развернуть ветку
Dmitry Podluzny

Обычно трудно себе представить объем работы, который может прятаться за такими, с виду простыми, интерфейсами. Мы тут перепроектировали одну страницу и один фильтр для системы мониторинга безопастности и это вылелось в 4 месяца работы и 82 прототипа (это чтобы покрыть сценарии и разных пользовательских условий), а количество иттераций можно и не считать. И то, на мой взгляд, получилось довольно сырое решение, которое надо было еще опкатывать. Хотя путь нащупали. А то, что коллеги вписали в 350 макетов, это учень немного. Рискну предположить, что еще осталось работ, которые можно было бы сделать в рамках проекта и ка можно было бы все поднять на еще лучший уровень.

Ответить
Развернуть ветку
Mike Ivanovich

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

Ответить
Развернуть ветку
Mike Ivanovich

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

Ответить
Развернуть ветку
Dmitry Podluzny

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

Ответить
Развернуть ветку
Mike Ivanovich

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

Ответить
Развернуть ветку
Dmitry Podluzny

Это иллюзия, что качество - это когда делается быстро, наверняка. Я бы даже сказал, если кто-то делает что-то быстро и наверняка, то или задача простая, или человек некомпетентный. Кривую Даннинга-Крюгера никто не отменял еще.

Ответить
Развернуть ветку
Дмитрий Щербак

«Красивый кейс можете посмотреть на нашем сайте». Переходишь и там все тоже самое, что и в этой статье 🗿

Ответить
Развернуть ветку
Mike Ivanovich

Извините, если что.

Ответить
Развернуть ветку
Mike Ivanovich

Триггерюсь на слово платформа )))))

Ответить
Развернуть ветку
Mike Ivanovich

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

Ответить
Развернуть ветку
Михаил Скворцов

Отлично, что макеты сделали) полгода — это не прям супербыстро для такого кол-ва экранов. Обычные типовые компоненты. Вопрос то не в макетах, а реализации. Было бы рабочее демо...

Ответить
Развернуть ветку
29 комментариев
Раскрывать всегда