А, ну и важно, это не абстрактная концепция. База есть, сделана в airtable, вот шаблон, можно посмотреть: https://airtable.com/universe/expShuhNMi0Oc0xpb/polaris-ux-nuggets

Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, scheduling встреч, составление отчётов)
https://blog.airtable.com/how-to-build-a-ux-research-system-that-runs-on-autopilot/
Ещё одна статья от WeWork "how to build a UX research system that runs on autopilot", на самом деле про то, как автоматизировать максимум рутины, если у вас маленькая команда исследователей в большой компании и вас разрывает от проектов.

1) Автоматизация рекрута: у ребят фоном работает НПС-опрос на клиентов. При низкой оценке клиенту автоматом отправляется второе письмо с просьбой поучаствовать в интервью (результаты НПС записывают в airtable, второе письмо шлют через https://customer.io/, всё без разработки на существующих интеграциях).
2) Автоматизация расписания: во втором письме (с просьбой участвовать) приходит ссылка на calendly со слотами для интервью, так что пользователи автоматом записываются в удобное для них и исследователей время. После выбора времени пользователю автоматически высылается письмо с приглашением и ссылкой на встречу в gotomeeting, а его контакты добавляются в airtable (смесь экселя и базы данных) в отдельную табличку (всё тоже настроено без помощи разработчиков, через интеграции в zapier).
3) Снижение затрат на обработку и отчёт: протокол ведут в том же airtable, в привязке к каждому из респондентов. Позже записи там же обрабатываются и превращаются в nugget из прошлой записи, база фидбека хранится в том же airtable.
4) В конце месяца из обнаруженных nuggets собирается письмо на команду с основными находками по разным проектам. Т.к. хранится всё в одной базе, собирать по презентациям не нужно, легко вытащить все данные за последний месяц по конкретному проекту.

Сам подход является продолжением идеи WeWork про continuous user research, когда вместо чётко очерченных исследовательских проектов постоянно проводятся open-ended сессии исследований без чётко структурированных сценариев. Подготовка к таким исследованиям почти не занимает времени, а результаты доставляются команде не в виде отчётов, а в виде постоянных пополнений базы инсайтов (о которой я писал в прошлой записи), плюс иногда делаются срезы (например, на скрам-митинге исследователь может рассказать, что нового узнал за прошедшие две недели).
Мне кажется, это здорово подходит для плотной команды с двухнедельными спринтами, и это, наконец, способ вписать исследования в аджайл.
https://medium.com/@tsharon/continuous-user-research-in-11-6-seconds-57c27d1595c5

#ResearchNocode
#Operations

Google в 2011 сделали experience sampling, чтобы понять, чего добавить в поиск (и это опять был Tomer Sharon)
Так, у меня есть запрос на маленький нишевый инструмент для исследований, а ещё у меня для вас опрос, но начнём мы с кейса How Google Plans to Find the UnGoogleable:

Что делал Гугл? В 2011-м они захотели понять, в какой информации люди повседневно нуждаются, но не запрашивают её в поиске, чтобы понять, куда поиск развивать, и использовали experience sampling.

1) Experience Sampling выглядит так - вы берёте группу респондентов и через определённые промежутки времени задаёте им один и тот же вопрос, например "Что последний раз расстроило вас при посещении супермаркета?"
Вопрос стоит задавать в пару раз реже, чем происходит само поведение, например, если респондент заходит в магазин раз в день, вопрос про супермаркет задавать раз в два дня.

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

2) Гугл делали esm несколько лет подряд ежегодно, каждый раз охватывая около 1000 человек и получая около 20тысяч семплов опыта.

3) Всем участникам 5 раз в день на телефон присылали вопрос: "что вы недавно хотели узнать?" (What did you want to know recently?) Для сбора заметок использовали приложение Paco.

4) На выходе получили большую таблицу daily information needs, которые затем сгруппировали и приоритезировали.

5) На основе групп daily information needs придумали новые виджеты для поиска и для google now.

Вот тут Tomer Sharon (дада, это тот самый, что продвигал в WeWork atomic research,а сейчас раскачивает Goldman Sachs) рассказывает подробней https://goo.gl/w6Hrop
Вот приложение Paco, через которое они проводили, но оно не очень https://www.pacoapp.com
____
Другие кейсы исследований:
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
https://t.me/uxread/24 - Ребята из Playstation тестируют VR игры
https://t.me/uxread/103 ИКЕА классно спрашивают про human experience
https://t.me/uxread/30 как Mozilla исследований использование закладок в браузере, запрещая ими пользоваться (и про то, как люди сохраняют нужную им информацию в интернете)
Другие кейсы исследований #Cases

Теперь про запрос на инструмент, я не нашёл нормальных приложений для экспириенс семплинга. Мне кажется, метод недооценен, можно раскачать, а все текущие решения, которые я нашёл, страшные. Я готов платить за подписку.
Понятно, что для сайтов и приложений можно всё делать через in app чатики, но если мы хотим узнать что-то про повседневное поведение, лучше отдельное приложение.

А, и опрос: https://goo.gl/forms/LH9k8QWquRCC4Rj22

Поговорим про Research Ops.
Тренд новый, до России докатился совсем недавно, и вот неплохое интервью с
Kate Towsey, Research Operations Lead в Atlassian и основателем research ops сообщества в целом.
https://blog.nomnominsights.com/researchops-spotlight-kate-towsey-research-operations/
Чтобы понять, что такое Research Ops, можно разделить задачи исследовательской команды на три группы:
1) Как произвести ценность - т.е. организовать и провести исследование и получить данные о пользователях, которые будут полезны бизнесу. Это то, что понимается под исследованиями в первую очередь, суть ремесла.

2) Как доставить ценность - обсудить данные с бизнес-заказчиками, превратить их в полезные задачи. Сюда же относятся воркшопы, ideation сессии, участие в продуктовых комитетах, вся административная работа, которая нужна, чтобы исследования стали полезными.

3) Операционные вопросы, которые вроде бы не про компетенции исследователя, но которые всё равно нужно решать:
- Где искать респондентов?
- Как GDPR влияет на рекрут и какие документы в связи с этим нужны?
- Как записываются видео и где они хранятся?
- Где найти софт, который пишет сразу с нескольких камер, а ещё скринкаст, но чтобы это был не morae
- Как организовать базу отчётов и инсайтов с исследований?
- Какие есть новые инструменты для сбора обратной связи?

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

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

Если это не про вас, и ресурсов на отдельного человека нет, всё равно советую посмотреть, что делает сообщества, там хорошо решают наболевшие вопросы:
1) Ссылка на запись в slack сообщество, с которого всё началось. https://docs.google.com/forms/d/e/1FAIpQLSeudMEcn9DLOebeomPMNgqCAVzIujzH8h76u0WaWASIMgvyxQ/viewform. Добавляют раз в месяц, но оно стоит того, много практичных советов.
2) Дарья Хлопова из Циана сделала сообщество в России и организует воркшопы (судя по презентации с последнего воркшопа, неплохие). На ближайшей встрече все будут обмениваться артефактами с исследований https://www.facebook.com/groups/reops/

(это не реклама Research Ops сообщества, я не знаком лично ни с Дарьей, ни с Кейт, но правда думаю, что встречи толковые, и на ближайшую собираюсь сходить)

Как Светлана Ратнер из Контура превратила менеджеров по продажам в исследователей
У исследователей часто стоит вопрос о том, как привлечь к исследованиям другие подразделения и распространить экспертизу. Особенно b2b и консалтинге, где эти "другие подразделения" часто знают продукт лучше, и чаще общаются с клиентами.
Светлана Ратнер рассказала о том, как превратила менеджеров по продажам в агентов исследований.
https://youtu.be/kz4fINVAano

1) Менеджеры постоянно общались с клиентами, но не умели структурировать требования и приносили их в формате "хочет зелёную кнопку вместо синей", без описания проблем и контекста.

2) Светлана сделала простой хороший скрипт для выявления потребностей:
- Какую задачу решаете?
- Какой результат ожидаете получить?
- Как будете использовать результат?
- Как действуете сейчас?
- Почему текущее решение не подходит?

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

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

5) Всё это за год дало около 700 чётких структурированных предложений от менеджеров, не в формате "клиент просит перекрасить кнопку" а с хорошим описанием потребностей и контекста. Класс.

Тут просматривается универсальная схема о том, как внедрять в команды новую практику:
- простой и прозрачный фреймворк (скрипт интервью, схема cj итд)
- обучение через обратную связь, а не просто через шаблон
- привязка к повседневным задачам и текущей мотивации, чтобы это не превратилось в практику ради практики.
____
Ещё про рекрут b2b и исследования без исследователей:
https://t.me/uxread/29 - Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://t.me/uxread/37 как в Контуре рекрутят b2b пользователей по конкретным темам через почту для обратной связи
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна в b2b
Ещё про поиск людей: #Recruitment
Ещё про исследования в b2b: #b2bResearch

Интересный подход к оценке ROI исследований и обоснованию их ценности.
Авторы предлагают воспринимать исследования (и UX, и маркетинговые, любые) как способ повысить вероятность правильных решений, область риск-менеджмента.
https://www.illuminas.com/wp-content/uploads/2016/03/innovationCan-we-measure-the-ROI-of-Market-Research-BIG-Conference-2009-Jonathan-Fletcher-and-Andrew-Reynolds-FI.pdf

1) В двух словах - они взяли портфель проектов, оценили потенциальную стоимость удачного и неудачного запуска каждого проекта, а исследование оценили как штуку, которая позволяет снизить риск неудачных запусков на 15%. И получили ROI.

2) Под эти 15% подведена весьма хлипкая теоретическая база - они сравнивают примерную точность decision making с исследованиями и без. Звучит так себе, в реальности метод не очень рабочий. Как все подобные подходы, он скорее риторический, чем математический, но зато из него следует несколько интересных выводов.

3) В таком подходе для оценки ROI исследований, бизнес должен хорошо понимать стоимость решений. Сколько будет стоить запуск новой рекламы? Сколько стоит выход на новый рынок? Сколько стоит реализация новой функции, сколько денег мы упустим, если этой функцией будет пользоваться только 5% клиентов из-за плохого онбординга? ROI исследований нельзя посчитать отдельно от метрик остального проекта, эту задачу нельзя сваливать только на исследователя.

4) Легче всего поэтому считать ROI для решений, стоимость которых бизнес умеет считать. Например каждый A/B тест стоит денег: это либо потери от запущенного плохого варианта, либо недополученная выручка от хорошего варианта, который вы не запустили раньше. Иногда мы заранее можем примерно оценить, сколько денег мы должны недополучить, чтобы считать разницу в A/B тесте статистически значимой. Если юзабилити-тестирование позволило принять решение без A/B теста (хотя это маловероятный кейс), мы можем посчитать его ROI довольно точно. Сюда же, если известна стоимость минуты работы оператора, то мы можем посчитать ценность небольших интерфейсных измеений с помощью GOMS.

5) Чем меньше стоимость наших решений, тем более дешёвые исследования имеют смысл. Для диджитал продуктов распространены простые исследования: 5 респондентов, небольшие интервью, быстрая обработка результатов или даже отсутствие обработки - решений много и стоимость каждого - невелика (ошибки можно исправить в следующем спринте). А вот в FMCG стоимость запуска нового продукта очень высока (также, как стоимость телеэфира для рекламы) поэтому имеют смысл более сложные исследования, навороченные лаборатории, длительные фокус группы, ЭЭГ, КГР и нейромаркетинг (ладно, насчёт нейромаркетинга я не уверен даже здесь) - чтобы повысить вероятность правильного решения, можно потратить деньги на сложные методы. Ребятам из классических market research бывает сложно перестроиться на быстрые итеративные lean исследования, потому что они привыкли проверять очень дорогие решения очень методично.

6) У одного и того же исследования может быть разный ROI в зависимости от того, какую информацию из него смогли использовать. Т.е. его эффективность зависит не только от исследователя, но и от заказчиков. У некоторых decision makers исследования не окупятся никогда в силу специфики принятия решений.

Вот ещё более общая (и более короткая) статья о подходе в целом. https://www.b2binternational.com/publications/research-for-decisions/amp/
____
Ещё про ROI исследований:
https://t.me/uxread/63 Как Athenahealth оценили ROI дизайна через регрессионный анализ
#ResearchROI

Как Superhuman научились оценивать product-market fit через измерение лояльной базы продукта
Нашёл забавную метрику для новых продуктов: вывернутый наизнанку НПС, который позволяет оценить, насколько продукт близок к product/market fit (то насколько ваш продукт нашел свою аудиторию и готов к росту) и превращает этот product/market fit из интуитивного ощущения в нормальную метрику.
https://firstround.com/review/how-superhuman-built-an-engine-to-find-product-market-fit/

1. Автор предлагает оценивать, какой процент пользователей будет разочарован, если продукт больше не будет доступен. Тут, как и в NPS, всего один вопрос: "how would you feel if you could no longer use the product?" с тремя вариантами ответов (very/somewhat/not disappointed). Нужно замерить процент ответивших “very disappointed” - это и есть наша метрика.

2. Они сделали бенчмаркинг по сотне стартапов и обнаружили, что быстрый рост начинается, когда хотя бы 40% пользователей говорят, что будут очень разочарованы, если не смогут больше пользоваться продуктом. Для примера, у Slack в 2015-м был 51%.

3. Проводить просто. Как и все подобные опросники, спрашивать можно через почту, мессенджеры или in app нотификации. Они говорят, что достаточно 40 человек (ну не знаю, а как же доверительный интервал), но нужно взять тех, кто пользуется продуктом хотя бы 2 раза в неделю (но я думаю, что для ситуативных продуктов вроде дримсим, мэпс.ми и hh тоже работает).

4. К главному вопросу можно прибавить ещё парочку, чтобы понять, как эту метрику растить.
- Для кого, по мнению респондента, продукт будет полезней всего
- Что в нём самое полезное
- И как можно это пользу увеличить.

5. Наконец, ответы можно дробить по группам клиентов, и смотреть, например, какие сценарии или функции вызывают наибольшее привыкание, или из каких каналов привлечения приходят самые преданные клиенты, и на основе этого планировать разработку продукта и маркетинговую стратегию.
___
Другие методы:
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/47 Google в 2011 поменяли поисковую выдачу на основе experience sampling
https://t.me/uxread/153 - как в Athenahealth применяют Technology Aсceptace Model для скоринга фич
Больше кейсов #Cases
Больше методов #Methods

Как Athenahealth оценили ROI дизайна и перекроили весь процесс
https://youtu.be/nG47ufRgY1k

Jennifer Cardello рассказывает, как у них в Athenahealth было 60 дизайнеров и 5 исследователей, а продукт всё равно был страшным и запутанным, потому что дизайнеров подключали для рисования галочек по запросу. А потом они устроили маленькую дизайн-революцию и всё изменили.
(С другой стороны, это история о том, как государство пыталось стимулировать электронное хранение медицинских данных, выделило 36$ дотаций и всё сломалось, а потом рынок всё починил).

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

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

2) Но! Постепенно ситуация изменилась, появились конкуренты, новые технологии снижали switching costs, а доктора (end users) оказались достаточно влиятельны, чтобы убеждать администрацию сменять поставщика. Все начали понимать, что потребности докторов уже не закрыть ad hoc рисованием галочек.

3) Дизайн-команда начала изменения именно с презентации об изменении рынка для бизнес-заказчиков. Не про дизайн, а про бизнес и новую роль дизайна в нем.

4) Дальше нужно было показать, что дизайн влияет на бизнес-метрики. Выбрали две - retention и referral users, дальше провели кучу опросников, позвали data science ребят, провели регрессионный анализ, показали, что customer satisfaction метрики действительно предсказывают отток и количество реферальных юзеров.

В третьих, там дальше чудная история, как они обучили продактов эвристкам Нильсена и заставили их оценивать 55 сценариев, и поменяли весь процесс принятия решений при проектировании продукта, но про это напишу попозже.
___
Про процессы в других компаниях
Mesosphere https://t.me/uxread/8,
Atlassian https://t.me/uxread/39,
Spotify https://t.me/uxread/104,
Facebook https://t.me/uxread/71,
Ableton https://t.me/uxread/123,
https://t.me/uxread/52 оценка ROI исследований через снижение риска продуктовых решений
#Companies
#ResearchROI