Майкл Марголис из Google Ventures написал статьи по исследованиям для начинающих
https://www.stitcher.com/podcast/inside-intercom-podcast/e/51156336?autoplay=true
Послушал интеркомовский подкаст с Michael Margolis, исследователем из Google Ventures, я выкладывал его фреймворк для планирования исследования "start at the end" выше, а тут словил ещё несколько деталей.
1) В GV около трёхста компаний, и он - единственный постоянный исследователь там. Поэтому он знает, как работать очень, очень, очень быстро.
2) Половину времени Майкл (Майкл? Мишель?) делает исследования сам - около 50 проектов в год (неделю на проект в рамках research sprint, который он тоже хорошо описывает), половину учит людей проводить самостоятельно. Каждую неделю есть office hours, когда ребята могут пройти к нему и вместе подумать дизайн исследования. Часть про обучение не менее важна.
3) Одна из фишек, спрашивать не "когда вам нужно это исследование" (всем нужно было ещё вчера), а "когда последний день, когда я могу дать результаты, так, чтобы они ещё были полезны". Кроме более реалистичной оценки сроков это заставляет команду заранее думать о том, зачем они делают исследование, и как будут использовать результаты.
4) Он собрал маленькую библиотеку статей про lean ux research http://www.gv.com/library/, подчеркивает, что это не для взрослых исследователей, а для начинающих стартаперов, но статью о "Rapid user research: how to survey 400 users and interview 10 in three days" я все равно прочитаю и перескажу, если она ок.
5) А, ещё он много рекрутит через крейглист. Стоит ли рекрутить через авито/юду?
От себя добавлю, что всё чаще слышу запрос от дизайнеров "научите нас тестировать, дайте нам шаблоны артефактов и помогите все придумать, проведём мы сами" , поэтому эти его статьи весьма в кассу.
___
Ещё про исследования для начинающих:
https://t.me/uxread/29 - Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://bit.ly/3iUF9vo Эмилия Городовых из Контура про то, как провести исследование самому
#Processes
https://www.stitcher.com/podcast/inside-intercom-podcast/e/51156336?autoplay=true
Послушал интеркомовский подкаст с Michael Margolis, исследователем из Google Ventures, я выкладывал его фреймворк для планирования исследования "start at the end" выше, а тут словил ещё несколько деталей.
1) В GV около трёхста компаний, и он - единственный постоянный исследователь там. Поэтому он знает, как работать очень, очень, очень быстро.
2) Половину времени Майкл (Майкл? Мишель?) делает исследования сам - около 50 проектов в год (неделю на проект в рамках research sprint, который он тоже хорошо описывает), половину учит людей проводить самостоятельно. Каждую неделю есть office hours, когда ребята могут пройти к нему и вместе подумать дизайн исследования. Часть про обучение не менее важна.
3) Одна из фишек, спрашивать не "когда вам нужно это исследование" (всем нужно было ещё вчера), а "когда последний день, когда я могу дать результаты, так, чтобы они ещё были полезны". Кроме более реалистичной оценки сроков это заставляет команду заранее думать о том, зачем они делают исследование, и как будут использовать результаты.
4) Он собрал маленькую библиотеку статей про lean ux research http://www.gv.com/library/, подчеркивает, что это не для взрослых исследователей, а для начинающих стартаперов, но статью о "Rapid user research: how to survey 400 users and interview 10 in three days" я все равно прочитаю и перескажу, если она ок.
5) А, ещё он много рекрутит через крейглист. Стоит ли рекрутить через авито/юду?
От себя добавлю, что всё чаще слышу запрос от дизайнеров "научите нас тестировать, дайте нам шаблоны артефактов и помогите все придумать, проведём мы сами" , поэтому эти его статьи весьма в кассу.
___
Ещё про исследования для начинающих:
https://t.me/uxread/29 - Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://bit.ly/3iUF9vo Эмилия Городовых из Контура про то, как провести исследование самому
#Processes
Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно
https://airbnb.design/moderating-the-back-room/
Airbnb пишут про модерацию back room. Так они называют комнату, из которой наблюдатели следят за исследованием, давайте назовём её обсерваторией (это ведь лучше, чем наблюдательская). Что говорят в Airbnb:
- Не услышанное исследование не считается сделанным (Research that doesn’t get heard, didn’t happen), поэтому от того, как заказчики наблюдают за исследованием зависит так же много, как от исследовательской части в самой лабе.
- Это значит, что поведение наблюдателей в back room/обсерватории тоже нужно модерировать, и для этого тоже нужен сценарий.
- Сценарий, который предлагают airbnb прост, изящен и похож на кусочек FAST подхода (https://t.me/uxread/27): вы вместе с заказчиками перед началом исследования выписываете ключевые вопросы/гипотезы исследования на реальную или виртуальную доску. В виде таблички: строки - вопросы, столбцы - респонденты. Во время исследования наблюдатели выписывают замечания по каждой из гипотез на стикер и приклеивают в табличку, т.е. по сути сами заполняют качественный протокол.
- Как и в FAST в конце каждой сессии и каждого дня вы выделяете минут десять и обсуждаете/добавляете наблюдения.
- К концу исследования у вас есть качественный протокол, сделанный вместе с заказчиками, который вы уже несколько раз обсудили.
___
Ещё про вовлечение заказчиков и респондентов:
https://t.me/uxread/27 это по сути реализация FAST фреймворка от Zoe Dimov
https://t.me/uxread/17 у Google Ventures есть свой Research Sprint - тестирования за неделю с сильным вовлечением заказчиков
https://t.me/uxread/30 Mozilla частично отдали обработку результатов самим респондентам
#Processes
https://airbnb.design/moderating-the-back-room/
Airbnb пишут про модерацию back room. Так они называют комнату, из которой наблюдатели следят за исследованием, давайте назовём её обсерваторией (это ведь лучше, чем наблюдательская). Что говорят в Airbnb:
- Не услышанное исследование не считается сделанным (Research that doesn’t get heard, didn’t happen), поэтому от того, как заказчики наблюдают за исследованием зависит так же много, как от исследовательской части в самой лабе.
- Это значит, что поведение наблюдателей в back room/обсерватории тоже нужно модерировать, и для этого тоже нужен сценарий.
- Сценарий, который предлагают airbnb прост, изящен и похож на кусочек FAST подхода (https://t.me/uxread/27): вы вместе с заказчиками перед началом исследования выписываете ключевые вопросы/гипотезы исследования на реальную или виртуальную доску. В виде таблички: строки - вопросы, столбцы - респонденты. Во время исследования наблюдатели выписывают замечания по каждой из гипотез на стикер и приклеивают в табличку, т.е. по сути сами заполняют качественный протокол.
- Как и в FAST в конце каждой сессии и каждого дня вы выделяете минут десять и обсуждаете/добавляете наблюдения.
- К концу исследования у вас есть качественный протокол, сделанный вместе с заказчиками, который вы уже несколько раз обсудили.
___
Ещё про вовлечение заказчиков и респондентов:
https://t.me/uxread/27 это по сути реализация FAST фреймворка от Zoe Dimov
https://t.me/uxread/17 у Google Ventures есть свой Research Sprint - тестирования за неделю с сильным вовлечением заказчиков
https://t.me/uxread/30 Mozilla частично отдали обработку результатов самим респондентам
#Processes
👍1
Как gov.uk тестируют понятность текстов с помощью highlighter testing (маркерных тестов)
Ребята из gov.uk предложили интересный способ тестирования контента (предложили ещё 4 года назад, но я то не знал): https://userresearch.blog.gov.uk/2014/09/02/a-simple-technique-for-evaluating-content/
Для меня исследование текстовых интерфейсов - большая боль, я часто сталкивался с запросами на тестирование лендингов, смс, текстов договора, интерфейсных подсказок и всего такого, и всегда казалось, что юзабилити-тестирования дают маловато фидбека и не помогают редактору написать хороший текст (и ощущаются как-то нелепо).
Этот способ называется Highlighter testing, и он лучше:
- Кусок текста распечатывают на бумаге (во всех описаниях метода подчёркивается, что надо печатать, а не с экрана, но думаю, это не так важно)
- Просят респондента разными цветами разметить слова и фразы, которые вызывают разную эмоциональную реакцию. В данном кейсе оценивали доверие сервису, поэтому просили зеленым маркером пометить слова, которые повышают доверие, и красным - те, что снижают. На деле признаки могут быть другими, можно добавить маркер для непонятных слов, для раздражающих слов, суть одна.
- Прогоняют несколько респондентов и строят общую цветовую карту, которая позволяет лучше понять язык, который понятен и удобен для клиентов.
- В комментариях есть лайфхак - прогнать такое исследование сначала на заказчиках, а потом на клиентах. Во-первых само задание заставляет заказчиков думать о тексте по-другому, а во-вторых цветовые карты заказчиков и клиентов интересно сравнивать, так как наглядно виден разрыв между ними.
___
Другие забавные исследования:
https://t.me/uxread/47 Google в 2011 поменяли поисковую выдачу на основе experience sampling (и это опять был Tomer Sharon)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Больше кейсов #Cases
Больше методов #Methods
Ребята из gov.uk предложили интересный способ тестирования контента (предложили ещё 4 года назад, но я то не знал): https://userresearch.blog.gov.uk/2014/09/02/a-simple-technique-for-evaluating-content/
Для меня исследование текстовых интерфейсов - большая боль, я часто сталкивался с запросами на тестирование лендингов, смс, текстов договора, интерфейсных подсказок и всего такого, и всегда казалось, что юзабилити-тестирования дают маловато фидбека и не помогают редактору написать хороший текст (и ощущаются как-то нелепо).
Этот способ называется Highlighter testing, и он лучше:
- Кусок текста распечатывают на бумаге (во всех описаниях метода подчёркивается, что надо печатать, а не с экрана, но думаю, это не так важно)
- Просят респондента разными цветами разметить слова и фразы, которые вызывают разную эмоциональную реакцию. В данном кейсе оценивали доверие сервису, поэтому просили зеленым маркером пометить слова, которые повышают доверие, и красным - те, что снижают. На деле признаки могут быть другими, можно добавить маркер для непонятных слов, для раздражающих слов, суть одна.
- Прогоняют несколько респондентов и строят общую цветовую карту, которая позволяет лучше понять язык, который понятен и удобен для клиентов.
- В комментариях есть лайфхак - прогнать такое исследование сначала на заказчиках, а потом на клиентах. Во-первых само задание заставляет заказчиков думать о тексте по-другому, а во-вторых цветовые карты заказчиков и клиентов интересно сравнивать, так как наглядно виден разрыв между ними.
___
Другие забавные исследования:
https://t.me/uxread/47 Google в 2011 поменяли поисковую выдачу на основе experience sampling (и это опять был Tomer Sharon)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Больше кейсов #Cases
Больше методов #Methods
userresearch.blog.gov.uk
A simple technique for evaluating content
I've been working with our content designers to refine content that explains the Identity Assurance service. We wanted a simple way to understand if our content inspired confidence in users or not. A simple technique and how it works At …
Светлана Ратнер из Контура про рекрут b2b пользователей по конкретным темам через почту для обратной связи
Светлана Ратнер из Контура рассказала о том, как находит замотивированных и релевантных респондентов для исследования.
(Отдельное спасибо Руслану Крючкову за организацию митапа и и запись с него).
- у Контура есть "юзер эхо" - почта, куда каждый клиент может написать свои впечатления или вопросы.
- когда нужно больше узнать о конкретном сценарии или исследовать прототип нового решения, Светлана находит релевантные отзывы в почте юзер эхо (как я понял, просто поиском по ключевым словам), и связывается с теми, кто их оставил (в форме обратной связи есть контакты).
- для клиента это выглядит не как исследование, а как сеанс персональной техподдержки - ему помогают решить проблему или рассказывают лучший способ решить задачу, а заодно расспрашивают о работе с продуктом и обсуждают с ним возможные варианты нового решения (тестируют прототип).
- такое исследование может дать более полные результаты, чем обычное "представьте, что вы оказались в такой ситуации...", респондентам важна проблема и они больше вовлечены в исследование, хотя результаты могут быть скошенными (в форму обратной связи пишут не все).
Я это к чему, большинство компаний, особенно больших, завалено обратной связью. Отзывы от продаж, тикеты поддержки, регулярные опросы клиентов, комментарий того парня на реддите, отзывы в Фейсбуке и ВКонтакте, отрывки личных бесед продакта с клиентами, всё это раскидано по разным табличкам, презентациям и письмам, и до дизайнера, например, доходит не всегда. Как это нормально исправить, насколько я знаю, никто пока не придумал, но можно начать хотя бы с рекрута - следующий раз, когда будете тестировать сценарий, попробуйте собрать у SMM, саппорта и продаж контакты людей, которые оставляли отзывы на релевантную тему (иногда отзывы можно найти полнотекстовым поиском по ключевым словам в их базе).
https://youtu.be/Mj6dG_cRJXY
___
Ещё про рекрут:
https://t.me/uxread/4 Как рекрутить респондентов через фейсбук
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна в b2b
https://t.me/uxread/46 Томер Шарон про автоматизированный рекрут в WeWork
https://t.me/uxread/60 Как Athenahealth (b2b, it системы для больниц) перекроили весь процесс дизайна
https://t.me/uxread/39 - процессы исследований в Atlassian
Больше про рекрут по тегу #Recruitment
Больше про b2b исследования по тегу #b2bResearch
Светлана Ратнер из Контура рассказала о том, как находит замотивированных и релевантных респондентов для исследования.
(Отдельное спасибо Руслану Крючкову за организацию митапа и и запись с него).
- у Контура есть "юзер эхо" - почта, куда каждый клиент может написать свои впечатления или вопросы.
- когда нужно больше узнать о конкретном сценарии или исследовать прототип нового решения, Светлана находит релевантные отзывы в почте юзер эхо (как я понял, просто поиском по ключевым словам), и связывается с теми, кто их оставил (в форме обратной связи есть контакты).
- для клиента это выглядит не как исследование, а как сеанс персональной техподдержки - ему помогают решить проблему или рассказывают лучший способ решить задачу, а заодно расспрашивают о работе с продуктом и обсуждают с ним возможные варианты нового решения (тестируют прототип).
- такое исследование может дать более полные результаты, чем обычное "представьте, что вы оказались в такой ситуации...", респондентам важна проблема и они больше вовлечены в исследование, хотя результаты могут быть скошенными (в форму обратной связи пишут не все).
Я это к чему, большинство компаний, особенно больших, завалено обратной связью. Отзывы от продаж, тикеты поддержки, регулярные опросы клиентов, комментарий того парня на реддите, отзывы в Фейсбуке и ВКонтакте, отрывки личных бесед продакта с клиентами, всё это раскидано по разным табличкам, презентациям и письмам, и до дизайнера, например, доходит не всегда. Как это нормально исправить, насколько я знаю, никто пока не придумал, но можно начать хотя бы с рекрута - следующий раз, когда будете тестировать сценарий, попробуйте собрать у SMM, саппорта и продаж контакты людей, которые оставляли отзывы на релевантную тему (иногда отзывы можно найти полнотекстовым поиском по ключевым словам в их базе).
https://youtu.be/Mj6dG_cRJXY
___
Ещё про рекрут:
https://t.me/uxread/4 Как рекрутить респондентов через фейсбук
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна в b2b
https://t.me/uxread/46 Томер Шарон про автоматизированный рекрут в WeWork
https://t.me/uxread/60 Как Athenahealth (b2b, it системы для больниц) перекроили весь процесс дизайна
https://t.me/uxread/39 - процессы исследований в Atlassian
Больше про рекрут по тегу #Recruitment
Больше про b2b исследования по тегу #b2bResearch
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году
На самом деле конечно есть системы для централизованного сбора обратной связи из кучи каналов, например https://nomnominsights.com, но одно дело инструмент, а другое - налаженные процессы, которые позволяют всё это поддерживать в нормальном состоянии, не превратить систему тегов в кашу, и не забывать использовать при работе над продуктом.
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году когда-то (в 13-м году) писали, что у них такое есть, база фидбека хранится в Evernote (не шучу, так и пишут), и все ей пользуются, пополняют и купаются в чистом полезном юзер фидбеке, но что-то я не знаю.
___
Ещё про базы инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
На самом деле конечно есть системы для централизованного сбора обратной связи из кучи каналов, например https://nomnominsights.com, но одно дело инструмент, а другое - налаженные процессы, которые позволяют всё это поддерживать в нормальном состоянии, не превратить систему тегов в кашу, и не забывать использовать при работе над продуктом.
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году когда-то (в 13-м году) писали, что у них такое есть, база фидбека хранится в Evernote (не шучу, так и пишут), и все ей пользуются, пополняют и купаются в чистом полезном юзер фидбеке, но что-то я не знаю.
___
Ещё про базы инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
Процессы исследований в Atlassian
Во-первых статья о том, как проводят UX-исследования в Atlassian (ребята, которые делают Jira и Confluence).
Всё как у людей:
- тестируют каждую фичу на прототипах
- до прототипах валидируют на интервью: "Prototyping actually comes quite late in the process for us, once we’ve validated a solution, and we’ve got a clear idea of what we want to do".
- делают быстрые итеративные исследования
- организуют воркшопчики с клиентами (стикеры, вайтборды, кодизайн, вот это всё).
Я всё надеюсь, что ссылка на джиру примирит с исследованиями самых лютых скептиков (тем более, что ощутимая часть продактов вышли из разработки и любят джиру нежной любовью), но пока не проверял.
https://www.justinmind.com/blog/how-atlassian-took-over-enterprise-software-qa-with-senior-ux-researcher/
____
Про процессы в других компаниях:
Mesosphere https://t.me/uxread/8,
LinkedIn https://t.me/uxread/121,
Spotify https://t.me/uxread/104,
Facebook https://t.me/uxread/71,
Ableton https://t.me/uxread/123,
Lyft https://t.me/uxread/11
IBM https://t.me/uxread/13 (чуть невнятно)
Больше про исследования в компаниях #Companies
Отдельно про b2b #b2bResearch
Во-первых статья о том, как проводят UX-исследования в Atlassian (ребята, которые делают Jira и Confluence).
Всё как у людей:
- тестируют каждую фичу на прототипах
- до прототипах валидируют на интервью: "Prototyping actually comes quite late in the process for us, once we’ve validated a solution, and we’ve got a clear idea of what we want to do".
- делают быстрые итеративные исследования
- организуют воркшопчики с клиентами (стикеры, вайтборды, кодизайн, вот это всё).
Я всё надеюсь, что ссылка на джиру примирит с исследованиями самых лютых скептиков (тем более, что ощутимая часть продактов вышли из разработки и любят джиру нежной любовью), но пока не проверял.
https://www.justinmind.com/blog/how-atlassian-took-over-enterprise-software-qa-with-senior-ux-researcher/
____
Про процессы в других компаниях:
Mesosphere https://t.me/uxread/8,
LinkedIn https://t.me/uxread/121,
Spotify https://t.me/uxread/104,
Facebook https://t.me/uxread/71,
Ableton https://t.me/uxread/123,
Lyft https://t.me/uxread/11
IBM https://t.me/uxread/13 (чуть невнятно)
Больше про исследования в компаниях #Companies
Отдельно про b2b #b2bResearch
Justinmind |
How Atlassian took over enterprise software: Q&A
Atlassian’s enterprise applications have changed the way teams work. Senior UX Researcher Georgie Bottomley tells us how If you work in tech today, it’s a fair bet...
Uber Eats сняли 360 видео про работу курьера чтобы вовлечь команду
Во-вторых, статья от исследователя из Uber Eats под громким названием "Using virtual reality to build empathy in distributed organizations".
Ron Goldin исследовал работу курьера Uber Eats в Токио (он сам сел на велосипед и развозил еду). Чтобы передать команде гнёт нависающих небоскрёбов и бесконечных эскалаторов, он записал своё путешествие на камеру 360, выложил в ютуб (ютуб сам склеивает видео 360) и разослал всем участникам команды гугл по картборду.
Потому что фотки и видеонарезки это хорошо, но ничего не передаст боль респондента и контекст деятельности лучше, чем видео 360.
- вот само видео (там две минуты всего https://www.youtube.com/watch?v=z86xTrMHU3c&feature=youtu.be)
- Вот камерка за 200$ для съёмки видео 360
https://www.amazon.com/Insta360-Nano-Degree-Seamless-Stitching/dp/B01FY8CHIA (статья годичной давности, сейчас мб и подешевле есть).
- А вот сама статья https://medium.com/uber-design/using-virtual-reality-to-build-empathy-in-distributed-organizations-8cb70b138c6c
____
Ещё про вовлечение команды:
https://t.me/uxread/35 Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
https://t.me/uxread/27 - Фреймворк FAST тоже предполагает вовлечение команды
https://t.me/uxread/71 - Facebook рассказывают про другие способы презентации результатов
Про другие способы презентации результатов #Presentation
Во-вторых, статья от исследователя из Uber Eats под громким названием "Using virtual reality to build empathy in distributed organizations".
Ron Goldin исследовал работу курьера Uber Eats в Токио (он сам сел на велосипед и развозил еду). Чтобы передать команде гнёт нависающих небоскрёбов и бесконечных эскалаторов, он записал своё путешествие на камеру 360, выложил в ютуб (ютуб сам склеивает видео 360) и разослал всем участникам команды гугл по картборду.
Потому что фотки и видеонарезки это хорошо, но ничего не передаст боль респондента и контекст деятельности лучше, чем видео 360.
- вот само видео (там две минуты всего https://www.youtube.com/watch?v=z86xTrMHU3c&feature=youtu.be)
- Вот камерка за 200$ для съёмки видео 360
https://www.amazon.com/Insta360-Nano-Degree-Seamless-Stitching/dp/B01FY8CHIA (статья годичной давности, сейчас мб и подешевле есть).
- А вот сама статья https://medium.com/uber-design/using-virtual-reality-to-build-empathy-in-distributed-organizations-8cb70b138c6c
____
Ещё про вовлечение команды:
https://t.me/uxread/35 Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
https://t.me/uxread/27 - Фреймворк FAST тоже предполагает вовлечение команды
https://t.me/uxread/71 - Facebook рассказывают про другие способы презентации результатов
Про другие способы презентации результатов #Presentation
Парные юзабилити-тестирования - два респондента обсуждают полученный опыт, выкладывая исследователю ментальную модель
Hossein Raspberry из UX Matters рассказал про парные юзабилити-тестирования.
- Он собирал пары из новичков и опытных пользователей, так, чтобы они проходили сценарий вместе.
- Пока они проходили сценарий, новичок задавал глупые вопросы, а опытный объяснял ему, как всё устроено. Это помогло вытащить ментальные модели обоих гораздо лучше, чем классический think aloud.
- Это позволило во-первых вытащить больше юзабилити-проблем при том же количестве респондентов (несмотря на сдвоенность), а во-вторых гораздо лучше понять причины проблем неопытных пользователей (например то, что они не понимают какие-то базовые концепции).
- Есть проблемы с доминированием опытных пользователей, но реже, чем можно было подумать.
Со своей стороны думаю, что это здорово подходит для профессиональных интерфейсов, где разница между новыми и старыми пользователями велика - CRM там, весь внутренний софт для операторов. Уже представляю, как в своём Акронисе сцеплю матёрых сисадминов с юными.
https://www.uxmatters.com/mt/archives/2018/09/case-study-adapting-a-software-development-technique-for-usability-testing.php
____
Про другие забавные методы
https://t.me/uxread/131 про разные стили модерации интервью - NNgroup и probing technics
https://t.me/uxread/89 Как проводить Кано
Больше методов #Methods
Hossein Raspberry из UX Matters рассказал про парные юзабилити-тестирования.
- Он собирал пары из новичков и опытных пользователей, так, чтобы они проходили сценарий вместе.
- Пока они проходили сценарий, новичок задавал глупые вопросы, а опытный объяснял ему, как всё устроено. Это помогло вытащить ментальные модели обоих гораздо лучше, чем классический think aloud.
- Это позволило во-первых вытащить больше юзабилити-проблем при том же количестве респондентов (несмотря на сдвоенность), а во-вторых гораздо лучше понять причины проблем неопытных пользователей (например то, что они не понимают какие-то базовые концепции).
- Есть проблемы с доминированием опытных пользователей, но реже, чем можно было подумать.
Со своей стороны думаю, что это здорово подходит для профессиональных интерфейсов, где разница между новыми и старыми пользователями велика - CRM там, весь внутренний софт для операторов. Уже представляю, как в своём Акронисе сцеплю матёрых сисадминов с юными.
https://www.uxmatters.com/mt/archives/2018/09/case-study-adapting-a-software-development-technique-for-usability-testing.php
____
Про другие забавные методы
https://t.me/uxread/131 про разные стили модерации интервью - NNgroup и probing technics
https://t.me/uxread/89 Как проводить Кано
Больше методов #Methods
Uxmatters
Case Study: Adapting a Software-Development Technique for Usability Testing :: UXmatters
Web magazine about user experience matters, providing insights and inspiration for the user experience community
Смотрите, как здорово, 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
Он назвал её 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 с выступлениями беженцев на сессиях ООН.
И, конечно, нам есть чему поучиться друг у друга. У журналистов есть постановочные фотографии (на следующее тестирование с вице-президентом обязательно позову специально подготовленного страдающего респондента), а у нас - вовлечение заказчиков в сессию исследования (не знаю, с чем сравнить. Стримы с места боевых действий?)
Развивая тему - книга Зонтаг написана о том, как менялась военная фотография от гражданской войны в США до конца 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
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
Medium
Democratizing UX
I’m excited to share Polaris, a new tool WeWork UX has launched to help WeWork become a better listening organization.
👍1
А, ну и важно, это не абстрактная концепция. База есть, сделана в airtable, вот шаблон, можно посмотреть: https://airtable.com/universe/expShuhNMi0Oc0xpb/polaris-ux-nuggets
Airtable
Polaris UX Nuggets - Airtable Universe
Tomer Sharon, the head of User Experience at WeWork and author of the books Validating Product Ideas and It's Our Research, considers Polaris "one...
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
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
For The Record
How to build a UX research system that runs on autopilot
Develop faster user insights by automating your research.
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
Так, у меня есть запрос на маленький нишевый инструмент для исследований, а ещё у меня для вас опрос, но начнём мы с кейса 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
YouTube
Google I/O 2014 - Don't Listen to Users, Sample Their Experience!
Tomer Sharon
Uncovering user needs is one of the most challenging aspects of product development. Oh-so-many organizations develop beautiful products and services nobody needs. The Experience Sampling Method is a simple research technique for uncovering…
Uncovering user needs is one of the most challenging aspects of product development. Oh-so-many organizations develop beautiful products and services nobody needs. The Experience Sampling Method is a simple research technique for uncovering…
🔥1
Теперь про запрос на инструмент, я не нашёл нормальных приложений для экспириенс семплинга. Мне кажется, метод недооценен, можно раскачать, а все текущие решения, которые я нашёл, страшные. Я готов платить за подписку.
Понятно, что для сайтов и приложений можно всё делать через in app чатики, но если мы хотим узнать что-то про повседневное поведение, лучше отдельное приложение.
А, и опрос: https://goo.gl/forms/LH9k8QWquRCC4Rj22
Понятно, что для сайтов и приложений можно всё делать через in app чатики, но если мы хотим узнать что-то про повседневное поведение, лучше отдельное приложение.
А, и опрос: https://goo.gl/forms/LH9k8QWquRCC4Rj22
Google Docs
Вопросы для исследований
Поговорим про 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 сообщества, я не знаком лично ни с Дарьей, ни с Кейт, но правда думаю, что встречи толковые, и на ближайшую собираюсь сходить)
Тренд новый, до России докатился совсем недавно, и вот неплохое интервью с
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 сообщества, я не знаком лично ни с Дарьей, ни с Кейт, но правда думаю, что встречи толковые, и на ближайшую собираюсь сходить)
👍1
Как Светлана Ратнер из Контура превратила менеджеров по продажам в исследователей
У исследователей часто стоит вопрос о том, как привлечь к исследованиям другие подразделения и распространить экспертизу. Особенно 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
У исследователей часто стоит вопрос о том, как привлечь к исследованиям другие подразделения и распространить экспертизу. Особенно 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
👍1
Интересный подход к оценке 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
Авторы предлагают воспринимать исследования (и 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