Смотрите, как здорово, Mark Hurst 10 лет назад придумал метрику, которая позволяет оценить, насколько команда и каждый из её участников customer-centric. Она проста, прозрачна, и её можно всем запихнуть в квартальные цели.

Он назвал её tesla (Маск ни при чём): time elapsed since labs attended, т.е. "сколько дней прошло с тех пор, как человек был на исследовании/говорил с пользователями".
Забавно, что она отражает не просто количество исследований, а именно вовлечённость заказчиков: если вы делали исследование две недели назад, и дизайнер был на нём, tesla=10.
Если делаете каждый день, но дизайнер заходил только две недели назад, tesla=10.
А у кого тесла ниже, тот самый эмпатичный молодец.
http://goodexperience.com/blog/2008/11/one-number-to-grade-a.php

Простите, не могу удержаться от бессмысленной метафоры, у Сьюзен Зонтаг (американская писательница, философ и критик) есть книга "Regarding the Pain of Others" (смотрим на чужие страдания) и поразительно, что точно также мог бы называться учебник по модерации юзабилити-тестирований.

Развивая тему - книга Зонтаг написана о том, как менялась военная фотография от гражданской войны в США до конца 20-го века, как менялось изображение страданий, и как это повлияло на восприятие войны мирным населением.
Это напоминает статьи о том, как доносить до продуктовой команды проблемы пользователей - отчёты по результатам исследования можно сравнить с газетными сводками (которые влияют не слишком сильно), видео с исследований, понятно, с документальными фильмами, а воркшопы по дизайн мышлению и sponsor users с выступлениями беженцев на сессиях ООН.

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

Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся (а ещё про демократизацию исследований)
WeWork рассказывают про свой подход к исследованиям Atomic Research: они отказались от отчётов по исследованиям (совсем) и заменили их живой, постоянно пополняемой базой атомарных инсайтов. Тут идея такой глобальной базы описана лучше, чем где-либо ещё.

Обычно я шарю тут статьи десятилетней давности, но Atomic Research весьма свеж - 2018 год.
Сейчас расскажу:
1) Концепция отчётов и глобальных исследований устаревает - отчёты оседают мертвым грузом, их не читает никто, кроме исследователей, найти нужную информацию в старом отчёте сложно, результатов нет под рукой.
2) Чтобы изменить ситуацию, WeWork предлагают хранить research knowledge не в виде исследований, а в виде atomic unit of a research insight, который они называют nugget. Nugget это наблюдение (что мы узнали) + свидетельство (кусочек видео, аудио, скринкаст на 30 секунд) + система поиска (теги, которые позволяют найти наггетс по сценарию, контексту, паттерну итд). Все эти кусочки хранятся в единой базе.
3) По результатам исследований база пополняется, сейчас таких кусочков у них около 4000, туда попадают не только результаты юзабилити-тестирований, но и результаты маркетинговых опросов, a/b тестов.
4) Если отчёты оседают мёртвым грузом, то база живёт - любой участник команды может обратиться к ней и найти нужную информацию, в том числе из старых исследований.
5) Самое чудесное - можно составлять "плейлист" из таких кусочков и шарить с другими участниками. Плейлист позволяет смотреть данные в любом разрезе - если вы делаете чекаут, вы делаете плейлист из всех кусочков с исследований чекаута и шарите на всю команду, возможность собирать такие плейлисты юзер фидбека сильно влияет на качество дизайна.
6) Цель, которую они ставят перед собой - сделать базу источником эмпатии по нужной теме в том числе для топ-менеджмента и CEO, т.е. в идеальном сценарии он может не просто просмотреть отчёт по теме, но и увидеть живые видео и отрывки интервью, связанные с проблемой, которая для него важна в данный момент.

Вот базовая статья по теме https://medium.com/@tsharon/democratizing-ux-670b95fbc07f
Вот некоторые пояснения:https://medium.com/@tsharon/the-three-most-popular-questions-about-atomic-research-56a5414d3d17
Ещё немного подробостей и некоторые рекомендации по системе тегов https://medium.com/@tsharon/foundations-of-atomic-research-a937d5da5fbb
___
Ещё про базы инсайтов и распространение результатов исследований:
https://t.me/uxread/38 Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases

А, ну и важно, это не абстрактная концепция. База есть, сделана в 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$ дотаций и всё сломалось, а потом рынок всё починил).

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