Королёв про всё остальное (ex UX Research)

Что ещё можно посмотреть по теме:
- Очень хорошо про mixed research и конкретно про machine learning в UX пишет Антон в product science, вот его обзор области, а вот очень понятный рассказ, как они используют графы в продуктовой аналитике, с примерами и объяснениями, понятными, даже если вы в этом не шарите вообще (как я)
- Ещё один короткий кейс про графы, чем они лучше воронок, и как их использовать во имя конверсии

Ну и если хотите научиться руками строить простые предиктивные модельки и боитесь питона, у Куличевского есть практичный курс для новичков, я когда-то проходил, и теперь могу делать простенький машин лёрнинг в гугл таблицах)

Machine learning для исследований на этапе формирования и проверки гипотез
Статья про использование machine learning для UX исследований от athenahealth
Эти знают, о чём говорят - вот кейс, где они построили регрессионную модель, чтобы обосновать ROI дизайна через NPS и ретеншн.

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

Они делят методы на три группы, в зависимости от того, какой тип задач исследователя они решают, и для каждой группы рассказывают про конкретные задачи.

Discover - по сути этап exploratory research. Чем тут поможет ML:
1) Персоны на основе кластеризации. У вас есть набор данных пользователей с признаками каждого, вы можете сформировать кластеры-группы на основе этих признаков. Тут не буду углубляться, в статье кратко описывают несколько видов кластеризации и их различия.
2) Association Rules - для выявления, какие события чаще встречаются вместе в одной сессии, или чаще встречаются для одного типа пользователей
3) Выявление частых сценариев (process mining) из неструктурированного лога событий аналитики. Это интересный кейс, когда вы хотите выявить какие-то неочевидные последовательности действий и пользовательские пути

Test hypotheses - этап проверки решений
Регрессия и деревья решений (decision trees) для предсказания того, какие события чаще ведут к целевому событию. Например, какие события в триальной сессии лучше всего предсказывают покупку, или какие параметры писем лучше всего предсказывают их конверсию, или какие параметры партнёров являются лучшим предиктором роста для них. В статье описано несколько типов регрессии, разница между ней и деревьями решений и даются ссылки на более подробные источники.

Data simplification - это, строго говоря, не про исследования, а про подготовку данных для анализа
1) Снижение размерности (Dimensionality Reduction) для более наглядного представления данных или их более простой обработки.
2) Подготовка данных, кратко описываются подходы и софт для подготовки.

https://link.medium.com/DNCUdct7I6
___
Ещё про исследования на разных этапах
https://t.me/uxread/13 - IBM про исследования на разных стадиях создания продукта
https://t.me/uxread/104 исследовательские процессы в в Spotify - mixed research и смешанный департамент product insights

В заметке ниже хорошие статьи про продуктовую аналитику

Тут интересно поразмышлять ещё о двух вещах:

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

И ещё о том, как возрастает роль hedonic qualities в любых системах со временем. Для b2с систем этот процесс произошёл несколько лет назад - интернет банки превратились в hedonic systems со сториз. Для b2b этот процесс идёт прямо сейчас - изначально b2b продукты это utilitarian systems, которые должны работать, и выполнять задачу, а субъективный опыт конечных пользователей не так уж важен. Но постепенно роль конечных пользователей в выборе софта растёт (slack, например, растёт "снизу вверх"), и b2b превращаются в hedonic systems (Athenahealth немного писали на эту тему https://t.me/uxread/60). Глобально для цифровых продуктов этот процесс идёт последние 50 лет, но про это я порассуждаю чуть-чуть попозже, пока уровень занудства не стал критическим.

Как имплицитное чувство вины за потребление мешает покупать красивые вещи (связка anticipatory guilt и hedonic consumption)
Исследование о том, как разные качества продукта влияют на решение о его покупке, которое заодно объясняет, почему люди дарят друг другу бесполезные подарки.

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

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

Авторы предполагают, что дело в "имплицитном чувстве вины за потребление" - неловко для себя желать слишком бесполезно-красивого. Эта гипотеза подтвердилась, хотя и очень опосредованно (они показали, что люди, выбирая продукты для других, испытывают субъективно более низкий уровень вины (anticipatory guilt from hedonic consumption)

Для нас это значит, что изменения hedonic quality (например, визуальные улучшения), вероятно, больше влияют на рекомендательные метрики (например, НПС), но меньше на готовность покупать и пользоваться продуктом самому.
Оп! В теории можно сделать продукт, которые все всем рекомендуют, но покупать его как-то неудобно.

Вот статья http://journal.sjdm.org/16/16428a/jdm16428a.html, опубликована на сайте Society for Judgment and Decision Making, там ещё много забавных.
___
https://t.me/uxread/68 Head of behavior science в Google
https://t.me/uxread/93 Канеман про работу памяти, дневниковые исследования и оптимальное время для опросов
Больше "околонаучных" заметок #Science

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

Среди клиентов, понятное дело, IDEO (ну ещё бы) и Big Three consulting firms. Цена - от 300$ до 900$ за одно часовое интервью, что, внезапно, меньше, чем я ожидал бы.
А, ну и конечно можно зарегистрироваться как эксперт, и получать свои миллионы.
https://deepbench.io/find

(UPD: Саша Фенин скинул пост с обзором таких сообществ, их миллион, оказывается https://t.me/startupoftheday/888)

И напоследок, если погуглить "probing technics" ещё немного, мы наткнемся на статью в блоге Gallup (у них есть блог! Пишут статей 5 в год, но пока не понял, толковые ли). Так вот, Gallup, и у них в статье указано, что не так всё просто, и probing искажает данные, так что надо аккуратней https://news.gallup.com/opinion/methodology/223286/effects-probing-survey-research.aspx
___
Ещё про модерацию:
https://t.me/uxread/79 Инди Янг про хейт спичи на исследованиях и как их переживать
https://t.me/uxread/120 можно записаться на исследования в другие компании, посмотреть, как модерируют
https://t.me/uxread/16 - Интерком про точечные интервью с пользователями, совершившим определенное действие на сайте
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
Другие методы #Methods
Другие кейсы #Cases

Но что ещё интересно, лектор провёл небольшое дополнительное исследование - как разные стили ведения интервью (нейтральный, поддерживающий и конфронтирующий "challenging") влияют на качество результатов, и обнаружил, что особо никак. Качество результатов для интервьюеров с разными техниками модерации не отличались. Но окей, это исследования на трёх десятках студентов, наверняка есть более глубокие работы на тему. Если читали что-то интересное - присылайте мне)
Сам курс хороший, хотя скорее с перекосом в философию науки, чем в практику. Если интересно только про техники вопросов, то вам, напомню, нужна неделя 4 урок 3)
https://www.coursera.org/learn/qualitative-methods

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

Он делит probing teсhnics на:
- Minimal probes - минимально инвазивные техники. Сюда входит затянутое молчание, хмыканье, отражение последней фразы - всё то, о чём пишут ребята Нильсена.
- Requests - разные типы уточняющих/проясняющих вопросов. Это довольно большая группа, и он выделяет несколько примеров - просьба привести пример, уточнить личное мнение, описать подробности итд.
- Summarizing and reflecting - разные способы резюмирования: "давайте повторим, правильно ли я вас понял, что…" итд.
- Miscellaneous - "другое" (какая же классификация без "другого"), куда он сваливает несколько разноплановых техник, на картинке есть примеры.

Это удобный чек-лист, которым можно пользоваться и для самопроверки. Я, например, часто перекрашиваюсь в summarizing, а minimal probes можно было бы и потренировать.

Про разные стили ведения интервью и probing technics
У NNGroup есть несколько замечательно практичных статей про модерацию интервью.
Вот классная о том, как правильно мычать в ответ на вопросы респондента, вы её видели наверняка, а если нет - посмотрите, там прямо войсы с примерами диалогов https://www.nngroup.com/articles/talking-to-users/
Или вот ещё одна хорошая - как помалкивать, тоже с аудиопримерами https://www.nngroup.com/articles/intentional-silence-ux/

Я к чему это - недавно прошёл курсеровский курс по qualitative researсh и там есть хорошее обзорное видео по probing technics (https://www.coursera.org/learn/qualitative-methods, неделя 4, урок 3)

Probing technics (русский перевод "зондирующие техники" меня пугает, оставим англицизм), это техники ведения интервью, от хмыканья до разных типов уточняющих вопросов - все те секретные секреты модерации, которые позволяют получить от респондента более глубокие и полезные ответы.
Сам термин, судя по всему, базовый для социологов, но не встречается в контексте UX исследований.

#Methods

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

Там ещё lifetime value в заголовке - особо не ведитесь, отдельных секретов про LTV нет, это чтобы продактам чаще в выдачу попадать https://bit.ly/3eZ5y9y
____
Другие забавные исследования:
https://t.me/uxread/82 Как headspace повышали вовлечённость и улучшали онбординг в приложении по habit formation loop (по пути проведя опрос и дневники)
https://t.me/uxread/30 как Mozilla исследовали использование закладок в браузере, запрещая ими пользоваться (тоже дневники)
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Другие методы #Methods
Другие кейсы #Cases

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

Первый - исследования в таком сакрально/гуманитарном ключе, как способ глубоко понять душу/разум/мотивацию пользователя с помощью, натренированной эмпатии и исследовательских практик.
Основная задача исследований - узнать что-то новое о людях. Это интересная задача сама по себе, безотносительно метрик. С этим подходом любят ассоциировать себя психологи/социологи/антропологи, и мне он интуитивно симпатичен. Но он же меня отталкивает, потому что:
- Допускает бесконечные бессмысленные споры об одних и тех же методологических вопросах по кругу
- Легко становится прибежищем для нейробулшита и научного шаманства (по логике: люди сложны->исследования сложны->нейробихевиоральный анализ в ходе когнитивного наблюдения поможет вам)

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

Где-то между ними, вне их есть ещё "исследование как нормальная научная дисциплина", где живут благословенные HCI ребята и Сауро (этих ребят тоже скашивает в споры о методологических вопросах, но меньше), но я не там.

(Простите за размазанные формулировки, это сырые размышления, которые мне важно записать).

Почему теперь я не уверен, что база инсайтов нужна:

1) Хранилище знаний не так важно, как налаженный процесс создания. Интуитивно кажется, что запас чего угодно (в том числе знаний) - это хорошо.
На самом деле - нет, потому что запасы впрок - это вложенные ресурсы, которые пока не приносят вам прибыли. Вы уже потратили время на исследование, но пока инсайт лежит в базе неприменённый, пользу он ещё не принёс. Чем больше таких неиспользованных знаний, тем больше времени вы пока потратили, не принеся ценности. Со временем инсайты "протухают" и становятся менее ценными.
(я понимаю, что Голдраттовскую метафору стоит использовать ограниченно, потому что знания можно переиспользовать, а детали - нет, но пока вроде нормально, да?)

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

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

2) Хранилище знаний не так важно, как налаженный процесс его доставки до команды. Одна из задач исследований - создавать user centered культуру и более сильное "чувство пользователя". Само наличие базы знаний эту культуру не улучшает, также как библиотеки сами по себе не повышают грамотность. Для этого нужно то, что Трэвис называет information radiators - постеры, встречи, дайджесты, т.е. способы не просто хранить знание, а доставлять его. Вы будете сильнее влиять на команду, если научитесь быстренько отгружать порции инсайтов и доносить их в понятной форме, чем если потратите время на огромный склад с системой хранения.

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

3) Почти ничего не важно. Третья причина (👨‍🦰🎶 🎹) в том, что мой внутренний фокус сместился от "как построить конвейер исследований, проверить каждую кнопочку, залезть пользователю в душу и ничего не упустить" ближе к "как понять, где важнее всего повысить качество решений, сфокусироваться на этом, и забить на остальное". Теперь не так хочется покрыть все продуктовые решения обратной связью, и большая всеохватывающая база знаний кажется не настолько важной.

Вести мы её всё равно продолжим) Посмотрим, как пойдёт.
___
Ещё про базы инсайтов
https://t.me/uxread/44 Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/38 Мейлчимп сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#bases

Как мы в Acronis вели базу 2 года, и почему разочаровались
Года полтора назад и ещё десять раз потом я ссылался на статьи Tomer Sharon про базу инсайтов, примерно тогда же мы сделали свою в Airtable, потом забили, потом начали опять, и сейчас, наконец, она начинает приносить пользу. Расскажу, как работает, и почему теперь я сомневаюсь в том, что она нужна).

Работает просто (если чётко понимаете, как у Шерона, можно скипать) - у нас есть таблица с кучей атомарных (понятных и ценных вне контекста) инсайтов, размеченных тегами. Когда кто-то хочет понять, как работает онбординг, как устроена обычная сессия работы с продуктом, или какие проблемы есть у раздела настроек, я могу по тегам найти нужные инсайты и сделать отчёт прямо в Airtable - он позволяет создавать и шарить кастомные view с преднастроенными фильтрами и отображением, более наглядные для широкой публики, чем стандартная таблица.

Можно сделать отдельные view для каждой продуктовой команды, а ещё отдельный для маркетинга, с упором на purchase motivation инсайты. Они будут играть роль дашбордов для качественных данных (view динамически обновляются, если вы добавляете в базу новые данные, которые попадают под фильтры). Это всё работает и действительно помогает быстрее отвечать на некоторые вопросы о пользователях.

Что ещё круто:
- Кроме скорости база даёт необычные ракурсы - можно увидеть, какие проблемы возникают, например, именно у профессиональных пользователей, или именно в маленьких компаниях, сделав общий срез для нескольких исследований.
- Теперь понятно, куда девать все нецелевые проблемы, которые вы получили "между делом", и которые не хочется терять, но прямо сейчас не к месту.
- База держится на идее атомарных инсайтов, которые должны хорошо восприниматься вне контекста отчёта, в том числе человеком, который про изначальное исследование вообще не знает. Это учит описывать проблемы более чётко.

Теперь минусы:
- Базу тегов для поиска довольно утомительно поддерживать. Пока наше решение - избыточность. Если пишу про проблемы алёртов, то ставлю теги "alerts", "troubleshooting" и ещё парочку, в зависимости от контекста, чтобы нужное точно нашлось. Из-за этого во view может попасть много нерелевантных инсайтов по теме, но они легко отсекаются сужением фильтров.
- Чтобы по тегам могли искать, нужно, чтобы у команды был общий язык для элементов интерфейса и сценариев. Формального процесса для создания общего языка нет, пока работает само. Новичкам может быть сложно, потому что они общепринятых терминов ещё не усвоили.
- На базу очень легко забить, особенно пока данных для нормальных срезов недостаточно и работать "по запросу" она не может. Чтобы этого не случилось, мы постарались использовать её для создания отчётов, которые не требуют красивой презентации, так мотивации заполнять больше.
- Не развалится ли это всё при масштабировании, когда людей, команд и инсайтов будет больше? Не знаю:)

Несмотря на плюсы, я теперь сомневаюсь, что базу стоит вести регулярно, поделюсь сочинениями чуть позже.
#Process #Processing #Research_repo