Блог

Выбор UX-исследования для кибербезопасности

• Цветков Максим
• 14.11.2020

Перед тем, как выбрать тип исследования, нужно определиться с целью исследования. У любого исследования должна быть цель. Цель это гипотеза. Без гипотезы вы не сможете правильно выбрать и сформировать задания к тесту, упустите все самое важное.

Гипотеза должна быть не одна. Запускать целое исследование ради 1-ой гипотезы — долго и дорого. Гипотеза должна быть четко сформулирована, а не абстрактное “пользователям более комфортно смотреть на фотографии котят”. Что такое более? На гипотезу должен быть четкий ответ да/нет в рамках качественного исследования и метрика в рамках количественного. И самое важное: гипотеза должна быть релевантна бизнесу. Если вы делаете инструмент для дизайнера, то нет смысла проверять гипотезу о потенциальной пользе подсказок о скидках на кулинарию. 

Тестировать можно не только интерфейс, но и навыки респондентов. Навыки работы с другими интерфейсами, или вообще понимание профессии специалистом, его знания. При низкой квалификации могут быть хорошие знания интерфейса конкретного вендора. Если есть понимание нормативной базы и стандартов (ISO 27001 -> ITIL -> COBIT), то о чем это говорит? Например, CEH/OSCP/COBIT очень расплывчивы по требованиям, а ISO 27001 более четкие. И опыт прохождения сертифткацит PCI DSS и SOC, являются ли критерием навыков специалиста?

Поиск респондентов

Всегда можно бесплатно или очень дешево найти респондентов, но качество будет варьироваться. Если мы хотим создать опрос и разослать его своей базе респондентов, то можно делать прямо в Google.Surveys, у которого после прохождения опроса рисуются красивые графики: /surveys.google.com/ Не путать с Google Forms, это уже другой сервис, Google опросы. Также есть http://cint.com. Это агрегатор панелей среднего качества, понятное дело, с наценкой. 

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

У каждого сервиса найма респондентов есть свои плюсы и минусы. Самый весомый минус бесплатных сервисов: если нет базы респондентов, то придется искать респондентов самостоятельно, обычно с помощью публикации ссылок на опросы в пабликах, группах вконтакте, рассылать друзьям, в чаты. В Gizmo, который я горячо рекомендую использовать студентам, есть встроенный checker качества респондентов. Формирует характеристики, если респондент 1 выдает ответы лесенкой, слишком быстро и т.п. Если мы говорим про опросы на международную аудиторию, а именно Юго-Восточная Азия, Южная Азия, ЛатАм (латинская Америка), МЕНА (Ближний Восток и Северная Африка), то тут два варианта набора респондентов, оба не бесплатных. Вы не найдете нужное количество чатиков/пабликов/форумов для закидывания бесплатной анкеты сразу на 20 стран. Поэтому либо таргетированная реклама через facebook. Либо платные панели, Qualtrics, в котором цена за респа в среднем 3–5$.

Есть агенства, а есть платные онлайн-панели, это готовые базы респондентов, которые согласились участвовать в опросах за небольшую денежку. Сервис respondent для зарубежных рынков, в основном США. Вы просто регистрируетесь, указываете параметры респов, привязываете карту, составляете скрининговую анкету, вам даются респоненты на выбор. Выбираете откликнувшихся респов по анкетам, можете человеку написать и порасспрашивать дополнительные вопросы. Назначаете время через панель, и вы проводите интервью, денюжка списывается. По цене от 50 до 100$ за человека +50% от этой стоимости самой платформе. Либо https://ru.toluna.com/#/ . Начать для СНГ можно с панели tiburon / fastuna.

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

Интервью

Самый рекомендуемый вид исследования, помогает ответить на многие вопросы и является базой для остальных исследований. Речь про one-on-one глубинное интервью с любыми людьми (от 20 минут до 6 часов). В таком интервью выясняем не факты, а интерпретацию фактов, отношение к определенной теме.

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

Перед интервью. Респондента надо встретить и поблагодарить за участие, уже на этом этапе могут возникнуть проблемы. Например, в 2020 году я должен был брать интервью у пятилетнего ребенка, он перед интервью взял анкету и начал ее заполнять. Заполнил вверх ногами. Или парень прошёл через металлоискатель, достал ключи, телефон, а потом оказалось, что он забыл достать пистолет. 

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

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

А теперь, как правильно составлять вопросы для Semi-Structured Qualitative Interviews. Первое и самое важное правило, нужно чаще задавать вопрос — почему? Пример диалога:

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

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

Второй пример из Toyota: Сел аккумулятор? → Почему? → Не работает генератор? → Почему? → Проблемы с ремнем генератора? → Почему? → Он долго не менялся, хотя изначально был хорошим. → Почему не менялся? → Машина долго не проходила ТО. Класс, несколько «почему», и мы находим первопричину. Дело не в ремне генератора, а в том, что надо напоминать о ТО. Эталонно должно быть не больше 5 «почему». Иначе люди бесятся.

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

What (что?) про детали происходящего. Что делает человек? В каком контексте? В ответе должны фигурировать прилагательные, отвечают на вопросы «какой», «какая», «какое», «какие», «чей», и постарайтесь быть как можно более конкретным.

В How (как?) опишите, как человек делает то, что он делает. Например, прилагает ли человек много усилий? Хмурится или улыбается во время выполнения задания? Использует ли много специальных инструментов, чтобы облегчить задачу? Попробуйте описать эмоциональное воздействие выполнения задания.

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

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

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

Будущее время. Если вы спросите человека: хотел бы он иметь самонаполняющийся стакан? Он ответит «Да»! Но при этом, если узнать, готов ли он его купить, то ответ будет «Нет». Люди хотят казаться лучше, чем они есть, и поэтому они будут отвечать на вопросы так, чтобы представить себя в лучшем свете. Особенно гики-парни по отношению к девушкам-исследователям.

Интервью отлично подходит для исследований в мире ИБ. Например, выяснение терминологии и классификация. ИБ это отрасль про подотчетность и наследуемость. Наследуемость про большие интеграционные сервисы, подотчетность про логирование событий для понимания, была ли информация скомпрометирована. Так и появилась потребность в тестировании защищенности, пен-тестерство. Существует 5 базовых параметров: угроза, актив, уязвимость, контроль и риск. Все они отражают суть профессии пен-тестера. Угроза может быть активная (атака), и не активная (где-то в мире есть вирус-шифровальщик, и он может нас атаковать). При грамотном построении ИБ неативные атаки легко отбиваются и активы не подвергаются угрозе. Актив это некая измеряемая информация, финансовые отчеты, информация о пользователях, сетевые пути — все это активы. Или узнать про типы атак. Они могут быть с обратной связью и без обратной связи. Обратная связь это получение доступа к базе данных и выполнение команды, а без обратной связи — ошибки в журналировании.

Специалисты эгоистичны, хотят поговорить о себе и своем опыте. В ходе интервью вы узнаете, как пользователю живется без вашего сервиса, например, как происходит инвентаризация на заводе ручками. Ничего не рассказывайте про свой продукт, даже про его идею. В конце интервью спрашиваете: «есть ли еще вопросы, которые мне следовало бы тебе задать?». Это работает, если вы наладили контакт. И второй вопрос : « с кем еще мне следует поговорить об этом?» могут порекомендовать новые ЦА, например, руководителей или системных администраторов. Но надо взять контакты. Если вы хотите углубиться в тему интервью, читайте книгу The Mom Test.

Самые популярные паттерны вопросов:

• Вводный вопрос “Можете ли вы описать последний раз, когда вы…?”.
• Зондирующие вопросы: Можете ли вы рассказать более подробно…?”.
• Уточняющие вопросы: “Что именно вы чувствовали в этот момент?”.
• Прямые вопросы: “Есть ли у вас опыт работы с Metasploit?
• Интерпретирующие вопросы, “Правильно ли я понимаю, что вы чувствуете, что…?”.
• Структурированные вопросы или закрытые, вроде — давайте вернемся К, давайте перейдем К.

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

Самое желанное для нашего мозга это спросить у респондента : «а в такой-то ситуации как бы вы стали себя вести?». Это страшный косяк. Правильный вопрос будет “Можете ли вы описать последний раз, когда вы…?”.

Небольшое упражнение. В утверждении «Злоумышленник получил доступ к новому телефону директора» есть несколько фактов: у директора новый телефон, у злоумышленника есть доступ, у директора есть телефон, злоумышленник сделал нечто плохое. И как будто бы все эти смыслы равнозначны в предложении, но это не всегда так.

Для проверки проводим тест отрицания: «Злоумышленник не получил доступ к новому телефону директора». И теперь не понятно, сделал ли злоумышленник нечто плохое. И пытался ли сделать? Это называется импликация, процесс формирования выводов из предложения.

Но кое что остается без изменений: у директора по прежнему есть новый телефон. Это пресуппозиция, то есть данность. А ведь можно переформулировать: «нет способа, которым злоумышленник получил бы доступ к новому телефону директора». У нас получается 4 прессуппозиции:

• у директора новый телефон
• у злоумышленника нет доступа к телефону
• злоумышленник не смог сделать ничего плохого
• у директора есть телефон

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

Вот два вопроса:

• В чем вы видите главную ценность продукта?
• Обладает ли продукт какой либо ценностью для вас?

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

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

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

После некого процесса создания прототипа, мы возвращаемся к интервью. Но уже проводим решенческие интервью (CustDev), когда есть продукт в виде MVP и можно формировать Early Adopters. Пытаемся понять, подходит ли решение клиентам и как улучшить MVP. Это больше про продажи. После проблемного интервью мы получаем набор инсайтов, реализуем решение и возвращаемся к тем же респондентам для валидации нашего решения. Эти люди вполне могут стать вашими early adopters. Если продукт решил потребность, то во время интервью вы сможете решение продать и получить первых клиентов. Подход называется Human-centered design, все версии дизайн-мышления строятся вокруг него.

Итак, глубинное интервью мы используем для выявления инсайтов по одной теме с наблюдением работы респондента (потребности). Глубокое погружение в опыт респондента. Особый акцент на раппорт и построение доверительных отношений.

Проблемное интервью для проверки гипотезы (сложности). У нас есть список гипотез о проблемах пользователя, и мы их проверяем в ходе интервью.

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

Формируется такой процесс:

•  гипотеза некой ценности
• интервью с клиентами для подтверждения гипотезы
• сегментация и уточнение ценности
• моделирование экономики
• MVP
• решенческое интервью и первые продажи.

В JTBD инсайд формируется по структуре ситуация — мотивация — ожидаемый результат, она же job story. Я обычно упрощаю до двух сущностей: задача/потребность и проблема/сложность. И далее, в airtable создаю следующую структуру для инсайда:

• Наблюдение: Знать планы о развитии продукта
• Команда: Front/Back Teams
• Уровень: Гигиена
• Этап CJM: Шаг 3 — формирование планов на спринты
• Тип: Проблема
• Сегмент: сотрудники офиса Армении
• Голосование: 4 голоса 

Техническая оснастка

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

JTBD

Популярная ошибка: исследователь уходит делать исследования, потом приходит и говорит «прошел коронавирус и серия бунтов по миру, скорее всего люди будут покупать больше в онлайне и будет увеличение инвестиций в социальные программы». И что с этим делать команде, спрашивается? Для решения такой проблемы существует JTBD. 

Автор фрэймворка JTBD, Клейтон Кристенсен, профессор Гарвардской школы бизнеса, определяет концепт Jobs To Be Done следующим образом: «Большинство компаний делят свою целевую аудиторию на сегменты по пользовательским или продуктовым характеристикам. Но у пользователя другой взгляд на рынок. У него просто есть задача, которую надо выполнить (job to be done), и он ищет лучший продукт, который поможет ему в этом».

У Клейтона Кристенсена есть книга «Дилема Инноватора», и «the innovator’s solution». В третьей главе он презентовал «job to be done». Это первоисточник. Мы рассмотрим важную для нас часть, а именно job stories.

Мое определение JTBD: процесс достижения цели под давлением определенным обстоятельств. Что позволяет нам предсказать, почему люди нанимают именно наш продукт для решения задачи. Это структурированный способ описания реальности. Раньше были популярны user stories c фокусом на пользователя. Job stories с фокусом на задачу, в какой ситуации пользователь человек имеет мотивацию и что-то делает, и у него есть ожидаемый результат. Job Story — это набор данных о потребности человека, укладывающихся в следующую структуру:

1. Ситуации, в которой возникла проблема;
2. Что, по мнению человека, должно произойти, чтобы проблема решилась (Мотивация);
3. Что человек получит, когда проблема будет решена (Ауткам).

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

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

Другой пример: утолить голод в торговом центре это работа для McDonald’s. Название job, и мы как потребитель нанимаем компанию для выполнения этой работы. Познакомиться с потрясающими оттенками вкусов французской кухни это уже рестораны со звездами Мишлен. Впечатлить девушку это один ресторан, покормить коллег по работе — другое заведение. Вот и вся суть JTBD, насколько хорошо наш продукт выполняет работу для пользователя.

Касперский строит лучшее в мире антивирусное решение, клиенты нанимают Касперского на закрытие потребности в обеспечении безопасности. И мы, как дизайнеры, должны подумать, а что если безопасность будет как сам факт, не будет хакеров, вирусов, промышленного шпионажа и прочего. Значит, мы будем конкурировать с Касперским не на уровне команды и технологий, а будучи косвенными конкурентами. Звучит очень смело и абстрактно, JTBD по своей задумке это инструмент очень высокоуровневый, без детализации. Хорошо работает, когда компания решает заходить на рынок со значительно более высокой ценой и с принципиально новым решением, в котором не будет старых критических задач. AirPods решило критическую задачу с распутыванием и подключением проводов лучше, чем проводные наушники. В итоге Core Job «слушать музыку с iPhone» делается лучше.

Значит, меняется восприятие услуги. Есть французский ресторан и пиццерия в рамках одного района. Являются ли они прямыми конкурентом друг другу? В ходе исследований может оказаться, что в пиццерию люди забегают за быстрой едой на работу или в дорогу, и тогда мы конкурируем не с рестораном, а с батончиками “Сникерс”. JTBD позволяет думать о конкурентах не на уровне категорий товаров, а на уровне задач.

Почему не персоны? Возраст, пол и привычки человека не объясняют, почему он съел батончик “Сникерс”. А наличие 30 секунд, чтобы купить и съесть что-нибудь, что избавит от голода на полчаса, это объясняет. Есть понятие Core Job (основные работы), на которые могут нанять бизнес. В супермаркете это будет   закупиться на неделю вперед, сэкономить на продуктах за счет скидок. Если у вас работающий бизнес, то важно найти клиентов, которые уже купили продукт и узнать у них про задачи, на которые наш продукт был нанят. Создать атлас задач и приоритизировать.

Немного про разницу между JBTD с Персонами:
JTBD это ответ на вопросы кто-что-как. Или: 
When _____ , I want to _____ , so I can _____ . => контекст, мотивация, конечный результат. Когда мне скучно, я хочу развлечься, и захожу в Facebook искать гифки с котиками.

“Когда ____” фокусируется на ситуации, “Я хочу ____” фокусируется на мотивации, а “чтобы я мог ____” фокусируется на результатах.

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

А JTBD:
«Владимиру было скучно, он решил купить подписку на Netflix.»
Его характеристики из Персоны не повлияли на его покупку. Он просто хочет развлечься, личность не учитывается. Учитывается ситуация, в которой люди находятся, это отсылка к другой школе психологии. И казалось бы, JTBD можно использовать вместо персон, но…. Между персонами и JTBD нет никакого противопоставления, они друг друга дополняют. Например, мои читатели очень разные, кто-то работает, кто-то может еще студент, кто-то хочет поменять работу, кто-то хочет подработку и жить на Бали. Вы, как персоны, будете скорее всего разные. Или Почта России, она покрывает практически все население РФ. Но работа одна. А когда продукт уже появился и закрывает некую работу, можно детализировать по персонам. Две сегментации — роль (таксист, пассажир, администратор с диспетчерской) и работа.  

Или мама из США выкладывает фото в интернет, как она жарит барбекью, и тинейджер в Тайланде выкладывет фото, как он рыбачит. Работа одна и та же, но персоны в корне разные. Можно сделать вывод, что персоны ограничивают аудиторию вашего продукта. JTBD про мотивацию, а персоны про роли. 

Но JTBD не идеальна. Персона это реалистичное описание конкретного репрезентативного представителя ЦА, со всеми характеристиками, которые сказываются на его отношении к продукту. Люди хотят веселиться? Они идут покупать игру. Но интроверты купят игру без социального взаимодействия, а экстраверты пойдут в командную игрушку. И персона это эмпатия, необходимое условие для построения коммуникации с клиентом через рекламу, позиционирование бренда.

Проблема с JTBD в том, что если работа закончена, то и роль продукта закончена. Надо четко выстраивать воркфлоу вашего продукта и продвижение пользователя по пути CJM. В CJM мы можем обозначить, где стартовая точка нашего продукта и конечная. И еще что было до нашего продукта, и что будет после. Это позволяет продукту быть достаточно нищевым, чтобы успешно конкурировать, и не пытаться покрыть необъятное, не уходить в ненужные направления. Но знать, откуда к нам приходят и куда уходят.

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

В целом это JTBD. Для чего он сгодится продуктовым дизайнерам? Для формулирования вопросов на интервью. Мы должны формулировать наши вопросы так, чтобы точно получить ответ на When _____ , I want to _____ , so I can _____ . 

В результате интервью вы должны не просто узнать, что пользователь хочет найти самые дешевые авиабилеты быстро. Тут фигурируют слова быстро и дешево, это не хорошо, это уже создание ограничений. Быстро и дешево априори не может быть хорошо. Или погодные приложения фокусируются на объеме осадков, давление воздуха и всевозможных прогнозах и множестве лишней информации, которая никого не волнуют. Пользователи пытаются ответить на простые вопросы, вроде “Будет ли дождь?” или “Насколько тепло будет?”. Клиенты редко покупают то, что продает компания.

Как более продвинутая версия JTBD, существует Goal-Directed Design, он больше про мотивы, окружение, что создает потребность в продукте. А JTBD концентрируется на продукте и его роли.

Есть 4 основных момента, которые отталкивают пользователя от потенциальной покупки или наоборот, мотивируют:

• Текущая ситуация: “Мой нынешний матрас довольно неудобен. Я просыпаюсь несколько раз ночью с болями в спине”. Push.
• Подталкивание к новому решению: “Если я получу новый матрас, я смогу лучше спать. Я буду в лучшем настроении дома и на работе”. Pull.
• Беспокойство и сомнения: “Что, если новый матрас окажется таким же плохим, как и старый? Я могу попробовать его только несколько минут в магазине”.
•  Привязанность к тому, что сейчас есть: “Этот матрас у меня с колледжа”

Но это примеры из мира оффлайна. Вот онлайн: 

• Push: “Мы хотим обрабатывать заявки пользователей быстрее, чем делаем сейчас. Наш текущий инструмент сильно ограниченный и дорогой.”. 
• Pull: “Новый инструмент обещает быть намного лучше, чем текущий, это увеличит скорость обработки заявок и соответственно, прибыль”. 
• Беспокойство и сомнения: “Что, если новый инструмент не интегрируется, как мы бы хотели? Мы попробовали еще три инструмента для этой работы, и ни один из них не был достаточно хорошо.” 
• Привязанность к тому, что сейчас есть: “У нас есть настройки рабочих процессов и интеграции, и было бы больно все это перенастраивать.”

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

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

Пример. Компания Apple “I’m a Mac” была очень успешной. Она выделила болевые точки Windows (1), продемонстрировала, насколько великолепен Mac (2), показала, как легко переключать (3), и представила тех, кто не будет переключаться, как шутов, уменьшив их привязанность (4) к старым привычкам.

Для оформления артефактов принято использовать классический JTBD Statement, вот его шаблон:

По вертикали: работы и в них отдельные ситуации, в которых они актуализируются.

По горизонтали: артефакты, которые описывают мотивацию человека в рамках одной ситуации, решения и требования к ним. А потом переходят в Job Stories или Ценностные предложения для связки с идеями продукта и коммуникации.

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

1. Какие проблемы и потребности есть у аудитории?
2. Кто является нашими конкурентами?
3. Как пользователи сравнивают нас с конкурентами и почему делают выбор в сторону конкретных решений?
4. Какие потребности мы удовлетворяем / не удовлетворяем?
5. Как развивать продукт, чтобы приносить больше пользы и победить конкурентов?
6. Как донести ценность нашего продукта и отдельных решений до аудитории?
7. Как улучшить опыт от использования нашего продукта?

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

Онлайн-анкетирование

Простейший способ исследования, и один из самых быстрых. Количественный метод. Программируете анкету и распространяете, благо, для этого существует множество инструментов. Вот самые популярные: Survey Monkey, Survey Gizmo, Google Forms, TypeForm. Также есть онлайн-панели, такие как яндекс.взгляд. Забиваете вопросы, и посетителям на яндекс.видео перед просмотром ролика показывают ваши вопросы. В своей работе иногда использую https://www.qualtrics.com и Фабузу. Для более простых проектов использую LimeSurvey, но его нужно устанавливать на свой сервер. 

Размер выборки. Работают правила из статистики с доверительными интервалами. 250 респондентов дают вам доверительный интервал +5% при 50% и 90% уверенности. Всегда нужно учитывать, что от всей аудитории, на которую вы делаете рассылку, лишь 10-15% пройдут опрос, если вы делаете рассылку (бывает меньше и больше, в зависимости от лояльности аудитории). В итоге рассчитываем размер рассылки по следующей формуле: размер рассылки = количество ответов х 10. Если аудитория не лояльна, то рассылаем на максимально возможное кол-во респондентов.

Есть Яндекс.Взгляд и Яндекс.Толока, которые умеют сами набирать респондентов. Но это платно. Можно настроить качество аудитории и еще несколько параметров. На Яндекс.Толоке можно создать опрос, а зарубежный UserCrowd позволяет задавать открытые вопросы в конце анкеты. Например, вы показываете респонденту картинку, и спрашиваете, насколько интерфейс дружелюбный. А так как слово «Дружелюбный» может трактоваться по разному, то важно уточнить, какой смысл респондент закладывает в слово. Так, любые обобщения: всякий, никогда, всегда, везде — нужно уточнять. Неопределенные существительные: любовь, страх, помощь, решение — нужно уточнять. Неопределенные прилагательные: качественный, выгодный, приятный, хороший — нужно уточнять.

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

Несколько правил:

• Пользователь не должен видеть следующий вопрос.
• Начинайте с закрытых вопросов.
• Ответы к закрытым вопросам надо оформлять кнопками.
• Не задавать наводящих вопросов. Всякие «мы решим вашу проблему, не так ли?» отметаются.
• Если анкета длинная, то респонденты не заполнят её до конца.

Про последний пункт поговорим подробнее. Я предпочитаю использовать следующую структуру опроса:

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

Почему демография в конце? Многие люди не заполняют демографию, возраст и пол. Если эти вопросы в начале, то люди закрывают опрос и уходят. На выручку приходит частичная запись. Если человек недозаполнил анкету и ушел, то данные потеряны (Google Forms и TypeForm). Но некоторые платные сервисы могут сохранить данные, и нам будет с чем работать.

И не используйте двойные вопросы, например: «сколько вам лет и город проживания?». Это сложно скармливать автоматическим системам анализа, и респонденты попросту не пишут полные ответы.

Проверка результатов опросов. Заполнены ли открытые вопросы, какое время ответа на вопросы, не были ли отмечены все все варианты во всех вопросах только А. Некоторые платформы имеют встроенную аналитику опросов: чем дольше человек отвечает на вопрос, тем больший вклад в нечестный ответ. 

Опросом можно выявить базовые ожидания от продукта. Так, у CVSS есть вектор атаки, выглядит он так Medium 4.5, CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:HЮ где каждая буква это значение угрозы определнного типа. Устраивает ли такое написание специалистов, или потребуется более наглядная визуализация?

Существует стандарт описания уязвимости (OVAL), это стандартный язык описания уязвимости для сканеров безопасности. Сканеры бывают разные. Бесплатные и платные, с разным набором фнкций, с поиском по CVE и без, поиском уязвимостей только в OS, компоненты по лицензии GNU GPL, интеграция с Metasploit, NVT. Умеет ли сразу устранить уязвимость (workaround), или mitigation для снижения последствий, сумеет ли установить обновления от вендора, или скажет что устранения проблемы не будет. И много другого функционала. Опросом можно получить информацию про весь ожидаемый функционал. Предварительно нужно ознакомиться с популярными сканерами: XSpider, Nessus, Сканер-ВС, OpenVAS из Kali, scanoval, Vulners, RedCHeck.

Для рынка америки существуют свои сервисы для опросов. Самый «на слуху» это Amazon Turk. Он же годится для рекрута респондентов. И Prolific, Condens, Dovetail, EnjoyHQ, MaxQDA. Для вознаграждения с закрывающими документами MyGiftCard для купонов. На рынок РФ, можно глянуть Anyfield.

Зачастую в опросах просят оценить по некой шкале, зачастую по шкале от 1 до 5 или шкале Лайкерта. Например: оцените, насколько вам понравился граф инцидента по номинальной шкале:

• Очень понравился
• Скорее понравился
• Средне
• Скорее не понравился
• Совсем не понравился

Формулировки вопроса можно украсить у ВЦИОМ, хотя и они косячат. Еще примеров:

Как давно вы анализируете инфраструктуру по новой версии MITRE ATT&CK?

• Сегодня впервые
• Меньше 1 недели назад
• Меньше 1 месяца назад
• От 1 до 3 месяцев
• От 3 до 6 месяцев
• От 6 до 9 месяцев
• От 9 месяцев до 1 года
• От 1 года до трех лет
• Больше 3 лет
• Затрудняюсь ответить

Возможна номинальная дихотомическая шкала, например: выберите, каким почтовым клиентом вы пользуетесь в своей организации. 1 = Outlook, 2 = BlueMail. Если подсчитать среднее по ответам, то мы получим 0.52, что считывается как 52% респондентов используют Outlook.

После проведения опроса выгружаем данные в Excel и творим магию. А именно удаляем тех, кто давал бессмысленные ответы, и скопом удаляем всех тех, кто отвечал на вопросы-ловушки.

User experience map, в англоязычной литературе чаще встречается термин core experience. Это очное интервью с респондентами, которые недавно решали определенную проблему. Наша задача узнать, как они решили проблему и визуализировать. User Experience Map это как человек может решить проблему без нашего продукта. Забегая вперед, скажу, что CJM это контекст некого продукта и может быть вида dream — в идеале, to be — реалистичное изменение, as is — как есть сейчас.

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

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

CJM—динамический артефакт. Так как карта стремится покрыть все аспекты опыта, то редко удаётся в одном исследовании получить всю информацию , это слишком долго и дорого. Поэтому мне нравится идея карты как рабочего артефакта внутри продуктовой команды, которую можно дополнять и уточнять. CJM совместный артефакт работы всей команды. К созданию карты должны быть сопричастны участники продуктовой команды — исследователи, продакты, дизайнеры, все те, кто активно формирует видение продукта. Карта помогает не упустить контекст, реальные задачи и боли пользователя. Делать цельную историю, а не набор фичей.

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

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

Перед созданием CJM строим персону, строим путь персоны (CJM), отмечаем провалы в сервисе, отмечаем эмоции, проблемы, цитаты, каналы. CJM это качественный вид исследования, в идеале, он валидируется количественно. Бывает и количественный CJM, например в uxpressia.

 CJM должно играть роль информационного радиатора, т.е. пассивного постоянного источника информации.

Фокус-группы. Продвинутый уровень исследований. На фокус-группу берут от 4 до 8 человек, это качественное исследование. Выборка должна быть гомогенной (один социальный слой), но без единых взглядов на вопрос. Если больше, то трудно контролировать. Можно встретить негативное мнение о фокус-группах, но в целом, это инструмент и надо уметь им пользоваться. Самое частотное негативное мнение это люди влияют друг на друга, или моментально формируется лидер мнения. Это вопрос умелого модерирования встречи в сторону групповой динамики. Модератор должен быть в позиции родителя и ни коем образом не давать обратную связь респондентам, так не будут искажаться ответы.

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

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

Usability-аудит. Экспертная оценка / эвристическая оценка .  Аудит выявляет, что мешает сайту быть удобным и понятным для клиента, что мешает совершить покупку. Обычно специалисту нужен доступ к системе сбора статистики GA. Одними эвристиками Нильсона уже не обойтись.

Попытаемся понять, как можно довериться сайту, чтобы избежать Man in the middle (MITM) атаки. Защита это сертификаты. Самая популярная это Domain Validated (DV SSL), который только про зарегистрированное доменное имя, т.е. довольно слабый. Следующий уровень это Organization Validated (OV SSL) , и третий уровень Extended Validation (EV SSL), которая для финансовых транзакций. Именно поэтому крупные магаины перенарправляют для оплаты товаров на сторонние страницы. Атаки называются SSL Strip и SSL Split. Это атаки уровня сетевой безопасности под маской сетевых атак. Сертификат угнали, подменили, сессию открыли и дальше злоумышленник вредит. MITM можно провести и на WPA2.

Кабинетные исследования (desk-research или Secondary research)— часто люди, которые не занимаются исследованиями, испытывают затрудения, так как не знают, с чего начать копать тему. Достаточно поискать в интернете. Помимо систем для анализа сайтов и трендов, можно подписаться на основные новостные и аналитические сайты по вашей тематике. И смотреть на государственную статистику стран, если работать на международный рынок. Такие параметры, как население, объем употребления услуг и товаров. Проблемы: данные устаревают, времязатратно, и нужной вам информации в интернете может попросту не быть.

Но контстаны, вроде количественной и качественной оценок уязвимостей, вполне можно изучать именно так. Количественная оценка это CVSS 3.0 для определения уровня опасности и CVE. Качественная оценка — экспертно назначенное значение, вроде опасно, критично, низкая, средняя опасность. Или простая методика светоформа зеленый / желтый / красный. Сканеры уязвимости помечают этими тремя цветами критичность риска. Количественная оценка риска уже сложнее, например, непрерывность ведени бизнеса.

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

Feature Table — сравнительная таблица . Подметод большой группы методов «Конкурентный анализ». По вертикали названия фичей, по горизонтали — продукты. Просто приведу пример:

Usability Testing — у нас есть юзабилти-лаборатория, в которой проводим интервью с пользователем, заодно тестируя продукт. Можем протестировать не только свой продукт, но и продукт конкурента, выявить его слабые стороны. Сценарий для интервью разрабатываем исходя из целей и задач. Например, выяснить мотивации, критерии для выбора продукта. Задачи должны вести к закрытию макро-цели:  исследовать, как продукт воспринимается.

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

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

Поделим вопросы на три типа:

• закрытый вопрос с ответом «да» или «нет».
• наводящий вопрос, в котором есть подсказка ответа
• открытый и однозначный вопрос, когда человек рассказывает историю.

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

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

Полевое исследование (Contextual inquiry)  — Полевое исследование это подвид исследований для поиска идей. Мы идем на рабочее место специалиста и смотрим, как он взаимодействует с чем либо. Можно понять, откуда берутся уязвимости в софте, наблюдая за специалистами и спрашивая. Обычно это ошибки в написании софта (buffer overflow), слабые/дефолтные настройки, особенности архитектуры на аппаратном уровне (meltdown). Или XSS — когда злоумышленник может интегрировать в страницу сайта некий вредоносный скрипт. Вопреки ожиданиям, XSS это проблема не сервера, а клиента. Браузеры по умолчанию не имеют защиты от XSS: Firefox требует установки плагина no-script, Chrome защиту убрал. XSS не всегда про кражу данных, часто это про установку рекламы, или создание точки входа в корпоративную сеть.

Тип атаки делится на активную и пассивную. Активная опаснее, код внедряется на сервер с кражой куки или воровством данных с формы, и все посетители сайта сразу становятся жертвами. Атака на куки это вся первая пятерка OWASP Top Ten. Пассивная атака это переход по ссылке, спам-рассылки и прочее.

Допустим, у вас есть навыки пен-тестера, и вы в состоянии взломать ПО. Вас, как исследователя, сажают в Red Team и вы наблюдаете, как команда ищет угрозы и старается расписать, как улучшить инфраструктуру у клиентов. Наблюдая, не забываем спрашивать. Люди вечно делают не то, что говорят. Смотрим, спрашиваем, документируем. Незабываемый опыт, который можно получить за нескольких дней в компрессорном цеху или взлома системы автоматического управления газоперекачивающим агрегатом позволит быстро влиться в область. Системы очистки и осушки газа, системы обеспечения бесперебойного электропитания, контроль качества газа с помощью датчиков, да даже банальные системы пожарной безопасности, защиты периметра и инженерно-технические средства это необходимый опыт для проектирования интерфейсов АСУ ТП. На любой ТЭС, ГЭС, ГРЭР, ГРЭС, SCADA-сервера будут генерировать миллионы измерений в секунду, и все это нужно отображать в понятном виде.

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

Один день из жизни — допустим, исследуем корпоративный телефон. Как человек живет со смартфоном в повседневной жизни. Мы, как спутник, весь день проводим рядом с человеком и наблюдаем. Маловероятно, что столкнемся с disaster recovery, но обычные задачи — вполне.

Пример посложнее. Находясь рядом с пен-тестером, мы можем понять, как строится атака. Увидеть, как специалист ищет недостатки прикладного уровня. Сетевая атака тянет за собой возможность произвести атаку на архитектуру или приложение, брутфорс слабых паролей в IoT, определение небезопасных протоколов, и так далее. И даже поиск аппаратных недостатков. Это куда интереснее, чем жить в парадигме типичной атаки: проникновение в корпоративную сеть -> закрепление в сети -> нанесение ущерба.

Понятно, что мы будем наблюдать только этичный хакинг, это то, чем занимаются отдельные сотрудники в рамках RnD. Существуют черные хакеры, серые и белые хакеры. И понятие корпоративной форензики, которое выросло из расследования кипер-преступлений. Примнительно к OWASP это pen-testing как выявление уязвимостей сетевого и системного уровня.

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

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

В случае с ИБ, для пен-теста берем parrotse, в нем есть набор предустановленных утилит, которые не нужно обновлять или скачивать. Помним, что любой пен-тест проводится исключительно после подписанного согласия клиента и на стороне клиента. Kali или Parrot будут машинами хакера. И XAMPP. Ставим все это дело на виртуалку. Настройки — минимум 2 GB оперативной памяти, 2 потока процессору.

И две машины жертвы, metasploitable и bwapp. Последний это лаборатория для отработки по топ-10, альтернативы ringzero и testphp.acunetix. Настроили и начали тестировать, какого это быть специалистом по ИБ.

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

Metasploit — полноценная машина для пен-тестера. Позволяет выполнять основные операции, всякие сканирования эксплойтов и полезные нагрузки. По сути, речь про автоматизацию, включает в себя REX, MSF Core, MSF Base. Существует две версии Metasploit: open source и коммерческая версия с очень крутым интерфейсом. Metasploit установлен в Kali. Достаточно прописать в терминале команду msfconsole

Далее, получаем доступ к множеству инструментов, таких как ifconfig, команда ls /usr/share/metasploit-framework/modules/ покажет список модулей, и сразу перейдем в каталог эксплойтов ls /usr/share/metasploit-framework/modules/exploits.

Observation/shadowing— то самое наблюдение. Можно расценивать записи веб-сессий как observations. Для информационной безопасности есть нюансы.

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

Перед «один день из жизни» лучше обновить свои знания по тематике. Хотя бы вписать nslookup + имя ресурса для поиска информации, для ленивых можно вспользоваться ресурсами sitereport.netcraft и robtex , второй поинтереснее по объему данных. Смотрим на SPF-записи, без этой записи нет защиты домена от несанкционироанного использования. Такая запись говорит, что некий домен имеет право отправки письма.

На основной сайт компании атаки из топ-10 производятся довольно редко. Обычно атакуют поддомен. Инструмент — sublist3r, он позволяет собирать информацию о поддоменах. У крупных компаний полно поддоменов, и любой из них может быть потенциально уязвим. Далее, идет примерочная атака, вроде фишинга. Злоумышленник может использовать сайты типа emkei.cz для рассылки писем от любого отправителя. Для создания временного ящика существует множество сервисов типа guerrillamail. И в тело письма можно вставить инъекцию.

Монадик (Monadic) — показываем один вариант картинки и респондент его оценивает. Все как в жизни, если мы показываем иллюстрацию на стартовом экране, то респондент видит только ее. Отвечаем на вопрос — как воспринимается?

Диадик  (Dyadic) — показываем два варианта картинки и просим оценить, какой выберут. У этого подхода есть минус, что мы просим выбрать из двух вариантов, но выбирать можно из двух плохих вариантов.

A/B-тест — количественное сравнение двух вариантов. Количественный метод со сложной математикой, можно почитать тут.

Системы сбора статистики — позволяют увидеть негативные тенденции и качественно их отследить. И отслеживать юнит-экономику.

По статистике мы сможем понять, какой язык программирования более устойчив к атакам по OWASP. По моим результатам исследований это C++ и iOS, а PHP в самом низу списка безопасных языков. OWASP — консорциум проблем информационной безопаснотси и всякие гайдлайны. У них есть набор мер по пен-тестингу. Особенно полезно знать про top-10.

Co-creation подвид большой группы методов ideation  из дизайн-мышления. Зовем на сессию дизайн-мышления тех, у кого есть проблема, и они вместе с нами пилят решение. Это не обязательно разработка MVP, вполне можно ограничиться карточной сортировкой или Tree testing (древовидное тестирование). 

Но можно пойти и дальше. Взять конкретный кейс и проработать его вместе с экспертами, узнать трудности и придумать решение для них. Возьмем фазинг. Файловый фазинг самый простой, некая программа должна открыть вредоносный файл. Фазинг делится на генерацию (случайный набор байтов) и мутацию (внесение изменений в корректный файл). В сетевых протоколах применяют только мутацию, могут либо просто портить траффик, либо по умному изменять данные для переполнения буфера. В Metasploit мало модулей для фазинга. Можно посмотреть доступные, используем команду use auxiliary/fuzzers/. Например, use auxiliary/fuzzers/ftp/client_ftp, устанавливаем контакт set RHOSTS 192.168.0.xx, и Run. Это основа DLC.

Для запуска атаки используются shell, они состоят из клиентской и серверной части. Делятся на подгруппы, такие как reverse shell для атаки через порт исходящего трафика. Meterpreter используется как оболочка для shell. Техника Meterpreter, благодаря dll-инъекциям, не оставляет следов. Другая техника это PassiveX для обхода фильтром исходящего трафика брандмауэра, NoneX, ORD, и много других.

Инъекции. Самые распространенные виды инъекций — вызывающие ошибки баз данных, слепые инъекции, булевые инъекции и инъекции для ошибок по времени работы баз данных.

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

Обойти это можно с помощью довольно простых преобразований <scriPt>, либо иньекция нульбайта %00 в конце, либо встроенные комменатрии /*!SELECT*/, или разделить на sel<ECT. Чуть посложнее это раздробленные запросы , попытаться переполнить буфер, IP-репутация.

Инъекция может быть строковй SELECT* from table where example = 'Example' или числовой SELECT* from table where id = 334.

Далее слабая аутентификация и управление сеансом. Аутентификация это верификация идентификации. По большей части, здесь задействована социальная инженерия, либо брутфорс паролей. Защита простая: сложные пароли, блокировка после неудачных попыток, ограничения по IP, хеши Session ID. Сразу напрашивается капча. Но эксперт скажет, что капче нужна защита от перебора. Если вы генерируете капчу на своем сервере, то нужна защита от DDoS. Итак, нужна ли капча? А если вы цель PSAO, то вам мало что поможет.

Для тестирования и сбора информации хорошо подойдет ssllabs.

Сoncept validation или Proof of Concept (PoC) — создание MVP. Не плохой способ проверить, что микро-сервисная архитектура добавила проблем с безопасностью. Устанавливая доверие между микро-скрвисами + архитектурные допущения для реализации такого доверия = дыры в безопасности.

Коридорное тестирование — делаем прототип, выходим в коридор и задаем два вопроса случайным встречным: что ты видишь и что ты понимаешь?

Итак, суммируем: понимание потребности > выбрать метод исследования (а может и парочки методов), что конечно редкость. Если ваши гипотезы подтверждены двумя разными исследованиями, то отстаивать находки куда проще. Хорошие пары:

• кабинетное исследование и интервью со стейкхолдерами
• опросы + фокус группы
• co-creation и обычное интервью
• полевое исследование + этнография
• юзабилити-тестирование + размышление вслух
• экспертная оценка + статистика
• a/b + экспертная оценка. 

Процесс: сделать дизайн исследования > выбрать способ ведения записей > начать исследование > получить результаты > затэгировать результаты > обсудить результаты, выровнять их со стэйкхолдерами > приоритизировать файндинги > создать отчет. По дороге можно обратиться к фреймворкам design thinking wayfinder, double diamond. 

Дневниковые исследования

Diary studies или дневниковые исследования относятся к продвинутому уровню. Это очень долгое исследование, пользователи живут с вашим продуктом в своей естественной среде обитания, время от времени отвечая на вопросы и заполняя отчеты. Исследование позволяет отследить во времени изменение восприятия продукта и не вмешиваться в контекст использования. Продолжительность от двух недель до двух лет, отчеты хоть каждый день. Отчеты могут быть текстом, голосом, эмоциональные видео. Из таких артефактов очень удобно строить CJM. Не все люди хорошо вспоминают негативные или позитивные ситуации из прошлого, даже если это было недавнее прошлое. В этом слабость интервью Поэтому дневниковое исследование позволяет получить фидбек именно в нужный момент. А если еще подрубить аналитику и смотреть статистику, сопоставлять с отчетами, можно создать прекрасную CJM.

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

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

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

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

Сроки

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

Новая фича потребует 5–10 дней или один полноценный спринт. Используем анализ конкурентов по теме фичи, интервью, обогащение CJM, юзабилити-тестирование. Идеально комбинировать с Dual-Track Agile.

Редизайн сервиса: 2 спринта, 20 дней. Потребуется большое исследование рынка, конкурентный аналих, user flow, много прототипов, новый UI-kit, тестирование на разных когортах пользователей. 

Новый продукт: 4 спринта или 40 дней. На первых этапах комплексные интервью с бизнесом, конкурентный анализ, создание персон, построение CJM с нуля, прототипы, тестирования. Для построения эмпатии обязательно интервью с экспертами, наблюдения в контексте и в окружении, анализ конкурентов, опросы.