Как мы используем полнотекстовую базу транскриптов интервью вместо базы инсайтов
Мы начали использовать для исследований связку Zoom+Otter.ai, и пока получается неплохо.

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

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

С Оттером ещё лучше - он умеет в живом режиме стримить субтитры со встречи. Этот транскрипт по ходу могут размечать, комментировать, добавлять в него картинки и скриншоты из зума все участники с team аккаунтом.
Т.е. на выходе с каждой сессии у вас уже есть размеченный транскрипт со скриншотами.

Во-вторых, корпус расшифрованных интервью с полнотекстовым поиском.
При интеграции с Зумом все записи интервью автоматически транскрибируются и хранятся в Оттере. По ним работает полнотекстовый поиск - вы можете по ключевым словам искать все цитаты респондентов, связанные с конкретной тематикой.
Искать можно по всем записям сразу, или по выделенным группам записей, что позволяет сформировать запрос вида "покажи мне всё, что b2b клиенты когда-либо говорили про billing integrations, на любом интервью за последний год". Кроме полнотекстового поиска есть возможность размечать текст комментариями/тегами.

Окей, вы можете быстро искать упоминания любой проблемы в своих интервью. Это уже неплохо, хотя если вы пользуетесь платформой для тестирований вроде uzertesting или uzerzoom, то у вас всё это уже есть - и авторасшифровки интервью, и разметка тегами, и полнотекстовый поиск, и всё это сделано удобней. Но тут есть другой момент

Расшифровка и база транскриптов из всех интервью, а не только исследовательских
Другой момент заключается в том, что сессии с клиентами проводят не только исследователи, но ещё и аккаунт-менеджеры, сейлзы, продакты, дизайнеры, и даже тимлиды, если вы угорели по демократизации исследований. Их вопросы и нужные им инсайты пересекаются, но вы едва ли заставите сейлзов делать отчёты, или вести базу инсайтов. И вы не станете покупать учётку Юзертестинга на каждого из них, а вот учётка Оттера стоит 20$ в месяц на человека, что позволяет в теории подсадить на него всех, и получать расшифровки сессий с клиентами, независимо от того, кто их проводит.

А это значит, что дизайнеры, наконец, смогут послушать, что новые клиенты говорят сейлзам про онбординг в продукте, продакты послушать запросы на новые фичи, которые озвучивают аккаунт-менеджерам, а маркетологи помониторить все упоминания маркетинговых материалов во обсуждениях с клиентами.
Вот это тотальная видимость, которую мы заслужили.
____
Ещё про способы хранения инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся

Про автоматизации и nocode в исследованиях:
https://t.me/uxread/122 Cally.ru - русскоязычный аналог Calendly для автоскедулинга интервью
https://t.me/uxread/8 Как Mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/46 Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, sheduling встреч, составление отчётов)
#ResearchNocode
#Bases

Написал про technology acceptance model - как устроена модель, как с помощью опросника предсказывать adoption фич до запуска, и насколько это валидно
https://bit.ly/3hoCGYs

Пару фактов вынесу сюда:
1) В 2019-м вышло метаисследование (обзор 114 работ) на тему того, что TAM предсказывает использование цифровых технологий учителями.
2) Для бизнес систем TAM позволяет объяснить от 15 до 60% использования.
3) Athenahealth с 17-го года используют опросник для concept validation - скоринга фич на этапе концептов. Опрос позволяет прореживать баклог и отсекать нерелевантные для пользователей функции.
4) Хотя все говорят, что спрашивать об использовании напрямую нельзя, во многих исследованиях attitude toward adoption (замеренный опросником) довольно здорово коррелирует с реальным adoption в будущем.
____
Другие забавные методы:
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/130 UX curve как опыт исследования опыт в динамике, дешёвая замена дневников
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
Больше методов исследований #Methods
Больше "околонаучных" заметок #Science

Скоро дочитаю Ульвика и сделаю нормальный пост про desired outcomes и инновации, а пока вот заметка имени Деминга про то, как оценивать компетенции и нанимать https://bit.ly/3iNtTkh

Вы наверняка знаете про "подталкивание" (nudge) - концепцию из поведенческой экономики о том, как влиять на решения людей с помощью позитивного подкрепления и непрямых указаний. Речь обычно о позитивных примерах вроде "если хранить здоровую еду на полках в супермаркете на уровне глаз, люди чаще покупают её и правильней питаются". И так в целом - когда пишут про nudge, чаще подразумевают "подталкивание во благо". В контексте UX термин используется редко.

Зато в UX часто используется другой термин - dark patterns. Концепции "nudge" и "dark UX patterns" очень схожи - мы стимулируем нужное поведение неявным образом, но в последнем случае скорее во вред пользователю, подразумевается "подталкивание во вред".

Концепция light UX patterns почти не встречается (пара статей на медиуме), хотя она очевидна, light UX patterns - уловки, которые стимулируют потенциально полезное для пользователя поведение - прочитать подробное описание продукта перед покупкой, использовать сложные пароли, потратить время на настройку сервиса под себя.
Тут можно порассуждать про звериный оскал капитализма (корпорациям не важно благо пользователей, только прибыль), или про то, что "вредные советы" часто виральней полезных (кроме случая с заповедями), но мы не будем.

Можно возразить, что при создании продукта почти все паттерны имплицитно light. Мы же в принципе создаём ценность для пользователя, все паттерны направлены на это.
Но на самом деле паттерны направлены на то, чтобы создать максимально продаваемый продукт, а не максимально полезный.
Польза и выручка могут конкурировать (у соцсетей высокий ретеншн но низкая полезность), могут коррелировать напрямую (в случае с utilitarian SaaS, ретеншн отчасти зависит от того, насколько продукт делает мою жизнь лучше), но редко совпадает.

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

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

Откровений в комментариях нет, но есть много интересных и наглядных примеров, вынесу сюда основные (тем более, это довольно частый запрос от бизнеса к исследованиям) https://www.facebook.com/lohmatyi312/posts/4671315759576757

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

2) Идеи из продуктового подхода:
- можно запустить продукт на чужой площадке (MVP маркетплейса в виде группы в фейсбуке)
- Отказ от автоматизаций (вместо разработки бота делать всё вручную, вместо умного ассистента отвечает группа ассесоров)
- Создание упрощённой версии на no-code инструментах (сделать всё на airtable)
- Использовать части других сервисов ("Когда делали визуальный конструктор для голосовых приложений, вместо того, чтобы сходу делать свой конструктор, взяли сторонний mindmap сервис, и вставили его через iframe к нам на сайт").

3) Из sales-first продуктоа
- Общий подход "сначала продать, потом делать".
- "Cold sales e-mails are the best, по конверсии сразу видно та ли аудитория и есть ли painpoint".
- Давать объявление о продаже на Юле, Авито и других маркетплейсах, ещё до производства. "Получил фидбек, измеряли количество обращений. сколько готовы ждать товар, как готовы платить и как удобно получать. Сделали первый заказ товара, продали, снова заказали. Market_fit."
- Запускать лендинг для проверки интереса к продукту до производства (http://plum.ac/, также запускали Рокетбанк)
- Можно даже без лендинга - для несуществующего сервиса делали объявления - лидосборники в fb, потом обзванивали и проводили интервью
- "В нашем случае, у нас все сервисы запускаются на руках агентов в чате. Декларируешь что есть сервис и побежал на заднем фоне делать под видом AI"

Кажется, исторически продуктовые исследователи не очень связывают себя с таким подходом. Никто не говорит "я умею проводить problem research интервью, а ещё умею придумывать MVP сервисов на нокоде, чтобы быстро проверить продуктовую гипотезу", хотя задачи в обоих случаях могут решаться схожие.

Понятно, что у таких подходов ограниченная применимость. Вы, вероятно, не сможете проверить так ценность новой функции в зрелом/сложном продукте. Вы не сможете проверить детали реализации фичи. И, наконец, большие компании (Банки, Телеком, в принципе не всегда готовы принять концепцию "давайте запилим лендинг несуществующего продукта на тильде", потому что комплаенс, служба безопасности, итд, и там культура таких экспериментов развита слабее.
Но я всё равно ожидаю, что таких запросов будет всё больше, и от исследователей всё чаще будут требовать подобных навыков.

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

#Methods

Ребят, я сделал русскоязычный аналог UX Coffee Hours - проект для обмена опытом между исследователями.
По сути это страничка со списком исследователей из разных tech компаний, готовых делиться опытом с коллегами.
https://researchtalks.ru/

Сценарий использования простой: вам нужен совет по конкретной проблеме (как делать mixed research, как нанимать синьоров, или стать синьором, или провести Кано итд), вы находите релевантного специалиста (в профиле каждого описан опыт и интересы), записываетесь на созвон по ссылке, и вперёд. Консультации бесплатные, длятся от 30 до 60 минут.

Уточню пару моментов:
- Проект в первую очередь про обмен опытом и получение "второго мнения" по конкретным проблемам, и в меньшей степени про поиск постоянных менторов.
- Отсюда профиль участников и формат описаний - старались делать упор на специализацию и уникальный опыт каждого. Кто-то хорош в кросс-культурных исследованиях, кто-то запускал хардверные продукты, кто-то круто автоматизирует процессы с помощью no-code, выстраивает передачу знаний в компании, умеет делать исследования рынка для привлечения инвестиций, или знает, как растить сильных специалистов.
- Если у вас есть интересный опыт, которым вы хотели бы делиться, можете написать мне, и я вас добавлю. Пока всё в ручном режиме, поэтому медленно и неторополиво.

https://researchtalks.ru/

___
- На английском есть похожие проекты: UX Coffee Hours и ADPList. По описанию они больше про карьерное консультирование (portfolio review, interview tips и всё такое), но тоже интересно.
- Есть отличное русскоязычное сообщество research ops, там тоже часто можно найти совет по конкретным проблемам, но оно закрытое https://www.facebook.com/groups/reops/

Очень смешная статья, на живую тему "can mess-loving UX researchers win over metrics-loving executives?", т.е. "как своими пятью респондентами и горой стикеров убедить менеджеров, которые любят цифры" (ёкнуло сердечко, а?). Супер инсайтов не будет, но это своё, родное, ресечерское, не могу не опубликовать.
https://uxdesign.cc/ux-researchers-win-over-metrics-loving-executives-b1b22104ea7c

Автор описывает знакомую нам проблему: вы проводите исследование на шести людях. Трое из них справились отлично, а трое вели себя странненько, не заметили здоровенный call to action на главной странице (как? Ну каак?), и начали хаотично гулять по сайту.
Вы приносите результаты вице-президенту, и он говорит “This was only 3 people from a sample of 6 — in a research study. Are we really going to change the site based on this? I’d like to see some bigger numbers …”.

В ответ исследователь выбирает один из 4 типичных ответов (ребята знают жизнь):
- "The Nielsen" (5 человек достаточно)
- "The More-of-the-Same" (ну ок, давайте ещё 5 интервью проведём)
- “The Buck Pass” (за количественной валидацией идите к аналитикам, это не к нам)
- "The Dismissal” (они ничего не понимают, давайте забьем, поищем заказчиков поумнее)

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

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

Про нарративную роль смешанных исследований (упс, немного высокопарно, извините) недавно здорово писали Spotify - интервью в чистом виде не вызывают достаточно доверия, чистые аналитические отчёты суховаты, а вот истории из смешанных данных полнокровны и убедительны: вот мы увидели паттерн на интервью, вот цитата респондентов про него, вот данные по двум тысячам людей, которые позволяют предположить этот паттерн у 40% пользователей такого типа.
___
А вообще толковей всех про mixed research рассказывает Антон Марцен. Можно подписаться на его канал, можно погуглить видео с кейсами, а можно пойти на researchtalks и записаться с ним поговорить)

#Cases

Года два назад писал про хороший способ тестировать интерфейсные тексты - highlighter testing, с тех пор несколько раз провёл, и выяснил, что тестировать так можно не только тексты, но и макеты, и даже список требований к продукту.

Напомню суть - вы даёте респонденту текст и просите разметить слова и фразы в нём разными цветами, в зависимости от того, какие эмоции эти слова вызывают: "выделите в тексте зелёным всё то, что вызывает доверие, а красным - всё то, что пугает".
Проводить можно на распечатке, в ворде, в SurveyGizmo или Oprosso (в обоих есть такой вид вопроса).
На выходе получается что-то вроде тепловой карты, отражающей удачные и проблемные места в тексте.

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

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

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

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

Как проводить, сколько времени закладывать
- Всё происходит очень быстро - пару дней от запроса до результатов. Как я писал выше highlighter testing есть в виде встроенного вопроса в Oprosso и SurveyGizmo, интерпретируется он так же просто, как first click. Я делал через гизмо, потому что мы пользуемся им в Акронисе исторически.

- Можно давать больше двух дескрипторов/маркеров за раз (до 4-х норм), но никогда не назначайте на один маркер две смешанные характеристики, вроде "отметьте красным то, что кажется глупым или непонятным, а зелёным то, что кажется умным и понятным, будет очень сложно потом анализировать. Да, это очевидно, но кто не делал глупых ошибок, верно?

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

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

#Methods

Немного про Ульвика, и про базу инсайтов на основе User Needs
Подход Ульвика к JTBD - трудоёмкий, но очень последовательный. Он говорит, что обычные jobs слишком верхнеуровневые, и на основе них продукт улучшать нельзя, поэтому предлагает дробить их на desired outcomes - более атомарные потребности (он подробно описывает, как это делать).
В одном из канонических примеров, у медсестёр в госпитале при использовании ранозаживляющего средства есть job "залечить рану", но внутри есть разные desired outcomes: "чтобы рана быстрее заросла" и "чтобы рана не стала хуже, не воспалилась". Это две разные потребности, за них отвечают разные качества продукта, и их можно маркетировать по-отдельности. Ульвик в исследовании обнаружил, что вторая потребность недообслужена - медсёстрам в первую очередь важно, чтобы рана не становилась хуже, а все производители продвигаются через "быстрее заживёт". Производитель поменял маркетинговую коммуникацию и в несколько раз увеличил долю рынка.
Подход Ульвика:
1. С помощью интервью найти и сделать полный список этих гранулярных outcomes для какой-то деятельности (в примерах Ульвика их порядка 100-200 на одну большую задачу, он проводит от 30 до 80 интервью)
2. с помощью опросов приоритезировать эти outcomes по важности и тому, насколько они хорошо закрыты (опрос на
3. разделить всё это по сегментам, выделить opportunity segment - т.е. сегмент клиентов с недообслуженными outcomes
4. выпустить продукт под эти outcomes, заточить маркетинг под них.
Вся последовательность действий (у него это не четыре шага, а, кажется 22) подробно и пошагово описана у него в статьях и книгах, большинство из которых бесплатны.

И вот статья, которая немного вернула мне веру в базу инсайтов - автор сделал для своего продукта полный список user needs, и группирует инсайты в базе по ним.
https://medium.com/researchops-community/user-needs-refinement-why-and-how-to-do-it-2ca4d28ade0d

Чем это круто:
- Сам по себе список needs/outcomes (об этом говорит и сам Ульвик) позволяет всей компании говорить на одном языке, и планировать и маркетинговые компании и продуктовые улучшения, отталкиваясь от общего списка конкретных микросценариев/needs. Сокращается разрыв между маркетингом, продуктом и исследованиями, когда продакты пилят фичи, маркетологи промоутируют уникальные технологии, а исследователи изучают поведенческие паттерны, и все почти понимают друг друга, но не до конца.
- Список outcomes конечный и более-менее фиксированный. Если вы пробовали делать базу инсайтов, то, возможно, знаете, что таксономия очень быстро расползается, становится сложно искать и ориентироваться, тут проблема отчасти решена.

Сама статья очень хороша и в ней куча примеров - куча скринов, примеры формулировок needs, и даже ссылки на драфтовую версию базы.
____
Ещё по теме:
- https://jobs-to-be-done.com/outcome-driven-innovation-odi-is-jobs-to-be-done-theory-in-practice-2944c6ebc40e - обширная статья Ульвика с описанием подхода
- https://strategyn.com/outcome-driven-innovation-process/ - бесплатная книга Ульвика по теме (там расписаны детали - как формулировать outcomes и искать сегменты)
- http://strategyn.com/wp-content/uploads/2019/10/Bosch-Case-Study-Strategyn.pdf - как Ульвик помог сделать лучшие на рынке США циркулярные пилы
- https://www.youtube.com/watch?v=ArpKdFH5HO8&t=0s - честный и классный рассказ ребят из Wrike о том, как они проводили исследование по Ульвику, но ничего не вышло
- https://medium.com/athenahealth-design/scaling-user-research-in-an-agile-r-d-organization-71f9be1097e2 мои любимчики, athenahealth, тоже делали исследование, и довольно удачно

#Methods, #Bases

Команда Авито вместе с ResearchOps сообществом запустили опрос про рынок UX исследований в России. Давайте мы все его пройдём.
Опрос занимает минут 7, заполнять его интересно, и лично мне он помог отрефлексировать процессы исследований в нашей команде (там есть классные вопросы-чеклисты про исследовательские практики)

Ну и на результаты интересно посмотреть, их опубликуют в открытом доступе https://anketolog.ru/e/13012968/zLZfahmE