Как уменьшить трения UX при разработке безопасных продуктов

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

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

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

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

Вечная битва между безопасностью и удобством

В течение десятилетий после рождения кредитной карты в 1950-х годах эмитенты, опасающиеся мошенничества, требовали от продавцов звонить им всякий раз, когда транзакция превышала «минимальный лимит» — максимальную сумму, которую владелец карты мог снять без предварительной авторизации. Это большая проблема для потребителя, ожидающего покупки нового автомобиля или холодильника. В результате, устанавливая минимальные лимиты, банкам и компаниям, выпускающим кредитные карты, приходилось взвешивать свою склонность к риску и терпимость своих клиентов к неудобствам.

Клиент с кредитным лимитом в 10 000 долларов, вероятно, имеет большую ценность для банка и более высокие ожидания в отношении обслуживания, чем клиент с лимитом в 1000 долларов. Вы можете решить поднять нижний предел для этого типа клиентов, чтобы свести к минимуму трения, с которыми они сталкиваются. Но что, если эти более ценные аккаунты также наиболее уязвимы для мошенничества? Вы можете в конечном итоге ввести уровень риска, который нанесет больший ущерб вашей прибыли, чем потеря некоторых из этих клиентов.

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

Меньше мошенничества не всегда означает больше прибыли

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

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

Банк, например, предпочел бы 100% защиту от мошенничества по многим причинам, в том числе:

• Удовлетворенность клиентов.
• Снижение потерь от мошенничества.
• Репутация бренда.
• Минимизация кибератак.

С другой стороны, у конечного пользователя есть конкурирующие требования: им нужен легкий и быстрый доступ к своей учетной записи. Этого не произойдет, если UX банка рассчитан на 100% защиту от мошенничества.

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

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

Зафиксируйте цели, затраты и допустимый риск клиента

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

Во-первых, определите текущий уровень мошенничества в банке и размер убытков, которые он может покрыть. Также взвесьте чистую экономию, которую компания надеется получить благодаря этому новому продукту, по сравнению с затратами на его разработку и поддержку. (Вы можете обнаружить, что защита от мошенничества стоит больше, чем само мошенничество.)

Далее прикиньте, сколько подозрительных случаев и «ложных срабатываний» сотрудники банка могут обработать в день. Ложные срабатывания случаются, когда банк удаляет или ограничивает учетную запись пользователя из-за просчета риска. Эти ложные срабатывания увеличивают трения для пользователя, отнимают время у банковских служащих и в конечном итоге могут нанести ущерб репутации бренда.

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

Определите, какие данные собирать от конечных пользователей

Безопасное программное обеспечение и приложения подтверждают:

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

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

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

Вместо этого начните с индикаторов, которые кажутся простейшими признаками личности пользователя, такими как местоположение, известные устройства и пароли. Затем подумайте о том, как злоумышленник может обойти эти индикаторы. Искушенные преступники могут подделать местоположение и устройство пользователя, а также получить доступ к паролям, скомпрометированным в результате утечки данных или атак вредоносного ПО. Чтобы закрыть эти лазейки, вы также можете проанализировать движения мыши или проверить, совершал ли пользователь подобные покупки в прошлом.

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

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

Внедряйте с клиентами для проверки ваших индикаторов

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

Фреймворк дизайн-мышления — это полезный подход к продуктам, которые обслуживают две группы пользователей. Он ориентирован на человека, а не на проблему, и просит дизайнеров сопереживать пользователям, чтобы они могли представить свои будущие потребности. Дизайн-мышление может помочь менеджерам по продукту разработать динамичный продукт, отвечающий конкурирующим интересам — в данном случае безопасности и удобству.

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

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

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

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

Соберите свои данные

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

Итак, как это работает в приложениях безопасности?

• Веб-браузеры: каждый раз, когда пользователь переходит на защищенный сайт в браузере, встроенные «сборщики» JavaScript собирают идентифицирующую информацию. Это может включать точки данных, такие как местоположение, сведения об устройстве и движения мыши.
• Нативные приложения. Нативные приложения предназначены для определенной платформы устройства, например iOS или Android. При доступе к службе с мобильного устройства эти приложения используют комплекты разработки программного обеспечения (SDK) для сбора идентифицирующей информации, которая может включать в себя касания пальцев и движения пальцем вместо движений мыши.

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

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

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

Для предприятий, построенных на электронной коммерции, затраты на эти замедления очевидны. В 2022 году Институт Баймарда подсчитал, что 17% брошенных корзин, которых можно было избежать, были вызваны слишком длительным или сложным процессом оформления заказа; еще 18% респондентов обвинили в недоверии к безопасности информации о своей кредитной карте. По оценкам Baymard, медленная проверка и отсутствие доверия к безопасности сайта были одними из факторов, которые привели к упущенным продажам в размере 260 миллиардов долларов в США и ЕС. Это дает невероятную возможность для менеджеров по продуктам электронной коммерции переосмыслить свои решения для торговых точек. Но независимо от вашей отрасли, снижение трения между пользователями и обеспечение уверенности в защите ваших данных должны стать постоянной практикой, которая может привести к более довольным клиентам и крупным бизнес-инновациям.

Вот два примера успешного снижения трения при разработке безопасных продуктов:

3ДС

В конце 1990-х Visa и Mastercard объединились для создания протокола безопасности 3D-безопасных платежей (3DS). Выпущенный в 2001 году исходный протокол требовал, чтобы все пользователи регистрировали свои карты в 3DS и входили в систему на каждой кассе с помощью специального пароля 3DS. Если пользователь не мог вспомнить свой пароль 3DS, он должен был восстановить или сбросить его перед завершением покупки. В более позднем выпуске у эмитентов карт была возможность заменить часто забываемый статический пароль динамическим одноразовым паролем (OTP). Однако дополнительный этап входа в систему продолжал мешать процессу оформления заказа.

Разработчики 3DS обратили внимание на это сохраняющееся трение и в 2016 году выпустили 3DS 2.0, которая включает компонент SDK, позволяющий приложениям встраивать элемент 3DS в свой код. 3DS 2.0 лучше подходит для мобильных транзакций и анализирует больше точек данных для более точной оценки рисков. В результате лишь небольшому проценту пользователей 3DS 2.0 необходимо пройти дополнительный этап аутентификации, часто в форме одноразового пароля.

Убер

3DS 2.0 — это пример снижения трения о продукте за счет итерации. Но вы также можете уменьшить трения на отраслевом уровне, внедряя прорывные продукты.

Бизнес-модель Uber построена на вычитании трения из традиционной поездки на такси. С Uber больше не нужно ждать такси или копаться в кошельке в конце поездки.

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

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

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

Лучшее техническое обслуживание — хорошее оскорбление

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

Ваша продуктовая команда должна предоставлять регулярные отчеты о ландшафте угроз и сопоставлять их с опытом и требованиями вашего клиента. Не каждая новая угроза требует обновления продукта. Возможно, ваша команда определила новый тип атаки, от которого ваш UX не защищает, но обсуждение с вашим клиентом показывает, что это не имеет отношения к их среде угроз: один банковский клиент в Южной Африке может столкнуться с целым рядом Мошенничество с подменой SIM-карты, в то время как другой в Нью-Йорке может подвергнуться большему количеству атак со стороны хакеров, использующих VPN. В большинстве случаев защищать оба банка от обоих типов мошенничества было бы невыгодно с точки зрения затрат и привело бы к ненужным трениям с точки зрения взаимодействия с пользователем.

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