Привет, Хабр! Меня зовут Павел Литвиненко, и я уже шесть лет как продуктовый дизайнер. Третий год работаю в «Лаборатории Касперского» в отделе Design and Research Office и с момента присоединения к компании занимаюсь созданием интерфейсов для Kaspersky NGFW вместе со своими коллегами Чечуриным Антоном, Пениной Валерией и Кузнецовым Максимом. До этого разрабатывал B2B-платформу торговли с закупщиками для производителя транспортной и потребительской упаковки, а также строительной и химической продукции.
С проектом Kaspersky NGFW я познакомился у самых его истоков, поэтому видел достаточно, скажем так, интересных интересностей. Пишу эту статью, чтобы поделиться, как начиналась разработка интерфейса нашего решения и через какие этапы мы проходили с теми, кто задействован в разработке продукта и с кем продуктовому дизайнеру нужно взаимодействовать, чтобы в итоге сформировать UX продукта.
Немного предыстории и размышлений
До прихода в «Лабораторию Касперского» я не сталкивался с темой информационной безопасности. Поэтому уже здесь начал учиться и погружаться в специфику ИБ-продуктов и в некотором роде сам стал немного ИБ-шником. К чему это я?
В рамках наших продуктов, внутри DRO нам необходим подход deep dive. Дизайнер, который работал до этого вне ИБ-тематики, обычно имеющий какое-то определенное представление о взаимодействии конечного пользователя с интерфейсом, не совсем нам подходит. Поскольку такое базовое, но неполное представление и понимание, на мой взгляд, составляет примерно 30 процентов от необходимого в случае с разработкой интерфейсов для ИБ-продуктов сегмента B2B. В случае ИБ у нас есть отдельные классификации типов персон, которые могут никак не пересекаться с базами пользователей других сервисов.
Есть дизайнеры, которым такого верхнего уровня понимания темы в целом достаточно для выполнения задач. То есть они получают перечень протоколов или что-то еще, для чего нужно сделать интерфейсы, раскладывают это по требованиям и начинают работать. Результат потом проверяется и корректируется продакт-менеджером, архитектором и другими вовлеченными в дело специалистами, и интерфейсы выстраиваются с учетом их мнений.
Такой подход позволяет быстро приступить к работе над проектом и сделать пригодный к использованию интерфейс. Но, по моему мнению, у такого подхода есть нюансы. Так как решение NGFW очень сложное, то итераций по корректировкам может быть много, а time to market для фич нужно сокращать. Поэтому для проработки качественного и удобного интерфейса для таких решений важно глубоко погрузиться в сценарии его использования, чтобы как можно скорее получать качественные драфты макетов. Важно понимать пользователей, которые являются целевой аудиторией продукта. Недостаточное внимание к их потребностям и привычкам может стать препятствием на пути к созданию действительно хорошей оболочки, особенно в случае с комплексным В2В-решением вроде Kaspersky NGFW.
Здесь пользователь — профильный специалист, а не клиент B2C-сервисов, которому обычно чем проще, тем лучше. Для спеца интерфейс — это часть его работы. Такого пользователя нужно изучить и понять, чтобы подстроиться под его майндсет и предложить более удобные и/или уникальные фичи для повышения его КПД. Наша задача не сделать так же, как у всех, а создать новые стандарты и решения на рынке. Человеку, отстраненному от темы, какой-то элемент интерфейса может казаться неудобным, излишним или контринтуитивным. А для специалиста этот же элемент будет удобнейшим решением, лучше других подходящим для выполнения рабочих обязанностей.
Поэтому, работая над продуктовым дизайном для Kaspersky NGFW, я стремился погрузиться в тему, стать отчасти профессионалом в ИБ и, что более важно, адвокатом пользователя. Это стремление порой приводило к жарким дискуссиям с коллегами. Например, разработчики, рассматривая вопрос под своим углом, могли считать определенные нюансы по умолчанию понятными и не стремиться лишний раз что-то подсвечивать в интерфейсе. Со своей стороны, я, как дизайнер, в некотором роде отстаивал права пользователя на понимание или непонимание каких-то вещей.
Чтобы сделать свое мнение более обоснованным и авторитетным, приходилось аккумулировать определенный технический бэкграунд, изучать механизмы систем даже не в плане интерфейса, а в плане разработки, понимать суть продукта. Это сложнее и дольше, но так на выходе получается интерфейс, который не только хорошо выглядит и сносно работает, но и сразу подходит под задачи и особенности аудитории.
Как выстроены процессы продуктового дизайна в «Лаборатории Касперского»
Перейду к рабочим моментам. Базовый сценарий выглядит примерно так.
Продукт-менеджер общается с клиентами и менеджерами компании касательно разрабатываемого продукта. На основе этих коммуникаций формируются бизнес-требования. Они — основа для архитекторов, которые прорабатывают структуру, по-своему отвечая на вопросы «где», «что», «как», «зачем» и «почему». Затем аналитики прописывают требования, формируется скоуп фич и релизы. После утверждения требований, получив запрос на создание интерфейса, в игру вступают продуктовые дизайнеры, приоритизируя задачи, выстраивая сценарии и начиная проектирование.
Конечно, общение напрямую с продукт-менеджером, архитекторами и аналитиками продолжается. Аналитикам временами приходится дополнять и видоизменять требования: с целостной структурой и системой продукта перед глазами становится понятнее, где и что можно улучшить, а что просто не сработает. Также коммуницируем мы и с теми, кто находится на следующем уровне — фронтенд- и бэкенд-разработчиками. Подсвечиваем баги, отслеживаем реализацию требований, сами подстраиваемся под общий темп. Иногда, если некоторые фичи с точки зрения дизайна проработаны глубже, чем сейчас можно реализовать, кладем готовые решения в бэклог, после чего расставляем их по релизам вместе с продукт-менеджером.
Но не всегда все идет по базовому сценарию. Например, если дизайн уходит вперед разработки, то работа ведется напрямую с архитекторами и продукт-менеджером. Аналитики затем прописывают требования и дополняют их по макетам для внесения нужных правок. Этот сценарий не идеальный, но жизненный :)
UX-исследования
Когда готова фича для важного сценария, наши коллеги из DRO-отдела UX Research проводят целевые исследования. Приглашаются специалисты, работающие с NGFW-решениями, которые затем участвуют в тестировании, «щупают» интерфейс и озвучивают плюсы и минусы выбранного подхода. В общем, вычисляется уровень удобства интерфейса фичи для пользователя. В число участников исследования входят не только коллеги из «Лаборатории Касперского», но и приглашенные эксперты от наших крупных заказчиков из разных отраслей, в частности финансов, логистики, промышленности и пр.
Фидбэк, собранный после общения с тестировщиками, анализируется и категоризируется по уровням «болезненности». Исходя из этого приоритета и объема выделенного ресурса наших фронтов, что-то берется в работу сразу же, что-то вносится в «пул UX-болей». Это табличка, где зафиксированы более низкоуровневые проблемы, описанные будущими пользователями продукта. Они также включаются в план для проработки на последующие релизы и, как видно на скринах ниже, достаточно активно реализуются.
В своей работе мы также базируемся на информации, полученной из качественных исследований. И чтобы в рамках продуктовой команды у нас была более простая работа с приоритетами, результаты тестирований мы оцениваем на основе шкалы SEQ (Single Ease Question). Например, на этапе релиза 1.0 смогли выдать хороший уровень пользователя (5,2), сравнимый с международными вендорами. Средний балл для аналогичных продуктов по шкале SEQ составляет от 5,3 до 5,6. Эти данные были получены исходя из исследований MeasuringU по более чем 400 задачам и 10 000 пользователей.
В нашем исследовании NGFW принимали участие сетевые инженеры с опытом работы с Checkpoint, Fortigate, Palo Alto и другими, в том числе российскими, решениями. В модерируемом юзабилити-тесте мы выясняли, удобней ли новый вариант дизайна в сценарии создания и редактирования правила. В число задач исследования входили:
Проверка удобства навигации через верхние табы.
Тестирование индикаторов вкладок source, destination и прочих.
Проверка заметности кнопок show all и used in rule.
Тестирование механизма с переключателем use any и кнопки disable all.
Отслеживание понимания таба all qualifiers.
Сбор обратной связи по всплывающему окну со списком объектов (также выясняем, нужен ли в этом окне поиск).
Тестирование, насколько заметней стали Security Engines во вкладке General при переносе опции включения логирования на верх страницы.
Проверка считываемости поясняющего текста под действием Inspect.
Как начинался продуктовый дизайн Kaspersky NGFW на примере Android и iOS
Знакомство с интерфейсами и сценариями начиналось с просмотра обучающих материалов других NFGW, уже доступных на рынке, таких как Checkpoint, Fortigate, Palo Alto и пр. Еще мы старались выжать максимум из общения с продукт-менеджером: выясняли мнения будущих пользователей и вникали в ход их мыслей, чтобы решить, в какую сторону направить разработку дизайна. Мы понимали: пусть это и специализированный под ИБ В2В-сегмент с определенными исходными данными, стандартами и глубокими настройками, к пользователю все равно можно подходить по-разному.
По результатам наших исследований я могу назвать FortiGate неким Android от мира NGFW: за счет структуры своего интерфейса он прост в освоении, что делает его лучше для новичка. В свою очередь, Palo Alto ближе к iOS: сложнее, но предоставляет более широкий функционал, что подойдет хорошо middle- и senior-специалистам. Мы же хотели за счет анализа конкурентов и обратной связи наших пользователей создать уникальное, но зрелое дизайн-решение. Доступное в освоении и понятное для развертывания «из коробки» как для новых, так и для уже матерых спецов, которые будут переходить на него со сторонних продуктов.
Подход к дизайну Kaspersky NGFW
Как я уже упоминал, мы ориентировались на Panorama, например, в навигации, и ряд других продуктов Palo Alto, а также Fortinet. При этом, само собой, стояла цель сделать лучше. Подсматривали определенные best practices, но, если уже созданные механизмы нас (а точнее, пользователей) не устраивали, мы придумывали свои с нуля.
У нас есть компонентная база, на которой мы строим интерфейсы: есть белые и темные компоненты. Выбор происходит автоматически, зависит от того, в какой сетевой теме у вас выставлено в верхнеуровневой платформе Kaspersky Security Center.
Здесь играл свою роль и технический аспект, из-за которого определенные решения не было возможности реализовать известными способами. В таких случаях тоже шли другим путем, придумывая концептуально новые техники. Ориентируясь на лидеров рынка, мы рассчитывали сделать наш интерфейс сразу понятным для пользователей. Хотелось упростить для них переход на Kaspersky NGFW. Переход на новое решение все равно потребует адаптации, это понятно, но мы стремились этот момент смягчить по мере возможности.
Сейчас мы прорабатываем как возможности для улучшения уже реализованных сценариев, так и идеи глобальных апгрейдов интерфейса. Что-то уже даже доехало до прода, а что-то пока ждет своего часа в бэклоге.
Ниже показаны некоторые из дизайнерских решений с описанием их проработки.
Пример 1. Создание правил фильтрации
Изначально наш сценарий создания правил фильтрации требовал в первую очередь создать все необходимые для него компоненты. То есть сперва создаются сущности, а потом их можно по одной добавить в правило. На первый взгляд это снижает вероятность ошибок при создании различных правил. Мы предлагали пользователю выбрать, какие компоненты подключить из глобальной библиотеки объектов. И уже далее подключали их к правилу. Но благодаря исследованиям и тестам с заказчиками мы выяснили, что этот подход не всегда удобен. Например, если такого компонента не было в библиотеке. Потому мы разработали сквозной сценарий создания правил. При необходимости пользователь может создать компоненты, а после добавить их в правило, как было до этого. Но в то же время теперь интерфейс позволяет вначале создать само правило, а уже после — его составляющие.
И все же интерфейс мы планируем обновлять. Когда мы проводили исследования, мы обнаружили, что его плотность недостаточно соответствует ожиданиям пользователей. В B2B-продуктах такие интерфейсы должны быть максимально насыщенными по плотности контента и функционала. Мы услышали пользователей и работали с нашей дизайн-системой, чтобы уплотнить интерфейс, кастомизировать, сделать его намного более эффективным и повыситьпроизводительность пользователя при взаимодействии с продуктом. Многие элементы останутся без изменений, но плотность компонентов на экране будет увеличена.
Как видите, что-то осталось таким же, но претерпело много изменений, то есть тут уже помещается намного больше разных наших компонентов.
Пример 2. Подключения квалификаторов в правилах фильтрации
А теперь для того же сценария — один из примеров тех самых жарких обсуждений внутри команды: реализация подключения квалификаторов в правилах фильтрации. Для бета-версий Kaspersky NGFW мы реализовали упрощенные варианты, чтобы весь функционал был доступен для тестирования. Но нужно понимать, что с точки зрения проектирования интерфейса выстроить вектор базовых механик важно для продуктовой команды и UX-продукта именно на таких этапах.
Вот пример проработки такой механики. В раннем сценарии мы действовали прямолинейно. Нужно добавить объекты в правило — открывается отдельное окно, пользователь выбирает нужные элементы и затем жмет на кнопку добавления, подтверждая изменение настроек.
На первый взгляд все хорошо. Но меня смутило множество сайдбаров, явный переизбыток кликов и этапов, через которые нужно пройти. Если бы это был сценарий, что проходится единожды при изначальной настройке, я бы, возможно, не стал настаивать на его переработке.
Но сценарий добавления квалификаторов в правило — повседневный. Единичная задержка в две-три секунды — это терпимо. А что, если пользователь будет создавать два десятка правил в день, и каждое — со своими квалификаторами? Эти лишние клики будут отнимать слишком много рабочего времени.
В итоге механику решили пересмотреть. Обновленный сценарий показан ниже – в нем мы объединили несколько этапов, которые необходимо было пройти, на один экран. В результате путь пользователя в создании правил стал короче.
В результате изменений мы существенно улучшили UX, так как сэкономили время пользователя и снизили его когнитивную нагрузку.
Пример 3. Навигация по продукту
Уровень удобства интерфейса повышается после принятия сотен решений. Какие-то из них могут быть совсем незаметны. Другие же, напротив, могут сразу броситься в глаза. Полный пересмотр подхода к навигации по продукту — пожалуй, из последних. Исторически сложилось так, что изначально мы разрабатывали дизайн для решения класса FWaaS и первоначальный интерфейс продукта сильно отличался от текущего. В NGFW добавились огромные разделы, например, для работы с девайсами и их шаблонами.
Навигационное меню выросло вместе с функционалом решения.
Выводы
За три года работы над Kaspersky NGFW я во многом изменил как собственный подход к продуктовому дизайну, так и, как я надеюсь, восприятие дизайнера командой разработки продукта. Когда мы начинали работать вместе, дизайнер считался приглашенным из соседнего отдела «аутсорсером». Он отрисует все, что указано в требованиях, и уйдет восвояси.
Поэтому стремление дизайнеров погрузиться в продукт и его разработку на первых порах вызвало недоумение, особенно у архитектора (привет Сергею Кравчинскому). Наше стремление поставить себя на место пользователей не могло не вызывать жаркие дебаты. Но от того, что дизайнеры стали полноценными членами команды, интерфейс Kaspersky NGFW только выиграл и будет выигрывать в будущем. Так как это не единичный подход к снаряду, а системные и процессные изменения, которые мы смогли реализовать на практике в продукте. Спасибо всей команде причастных.
