Что класть в базу инсайтов, а что - нет
Статья о том, что делать с находками с исследований, какие класть в базу инсайтов, а какие - нет.
Автор выделяет два типа находок - insights, которые описывают более стабильные особенности мотивации и поведения и findings, которые связаны с текущими деталями интерфейса и быстро устаревают. Insights нужно хранить в базе и на основе их развивать интуицию и "чувство пользователя" у продуктовой команды, а findings отправлять в джиру и планировать работу по ним как по обычным продуктовым гипотезам.
Само деление очевидно и не ново (я про себя делю на "классику", которую хранишь в библиотеке и используешь для создания базовых ценностей, и "периодику", которую важно прочитать, осмыслить и выбросить, смысл тот же самый), но в статье неплохие примеры и есть дерево решений, которое учит лучше эти два типа различать.
https://medium.com/@sticktail/how-to-write-valuable-user-insights-84b4290d94e8#5840
___
Ещё про хранение результатов исследований
https://t.me/uxread/44 Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/38 Мейлчимп сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
Статья о том, что делать с находками с исследований, какие класть в базу инсайтов, а какие - нет.
Автор выделяет два типа находок - insights, которые описывают более стабильные особенности мотивации и поведения и findings, которые связаны с текущими деталями интерфейса и быстро устаревают. Insights нужно хранить в базе и на основе их развивать интуицию и "чувство пользователя" у продуктовой команды, а findings отправлять в джиру и планировать работу по ним как по обычным продуктовым гипотезам.
Само деление очевидно и не ново (я про себя делю на "классику", которую хранишь в библиотеке и используешь для создания базовых ценностей, и "периодику", которую важно прочитать, осмыслить и выбросить, смысл тот же самый), но в статье неплохие примеры и есть дерево решений, которое учит лучше эти два типа различать.
https://medium.com/@sticktail/how-to-write-valuable-user-insights-84b4290d94e8#5840
___
Ещё про хранение результатов исследований
https://t.me/uxread/44 Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/38 Мейлчимп сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
Поучаствовал как респондент в интервью про базы инсайтов и ресёрч репозитории, которое проводит research ops сообщество. Модератор делала несколько интересных вещей, думаю перенять:
- Она в первые же минуты нашего разговора очень подробно описала весь процесс использования данных с интервью - кто будет иметь к ним доступ, как они будут расшифровываться, где будут храниться, какие задачи они хотят с помощью этого интервью решить, где и в каком виде планируют опубликовать результаты. Никогда не видел такого, очень здорово и вовлекающе.
- Сразу же при созвоне уточнила, комфортно ли мне говорить на английском, и извинилась за то, что не говорит на моём языке (это не было вызвано какими-то явными затруднениями с моей стороны - я говорю довольно свободно, но, позволило мне чувствовать себя комфортней, запинаясь).
- Чуть затянутые паузы после моих реплик. Я замолкал, после этого модератор ждала около секунды (пауза чуть длиннее естественной), и только после этого начинала говорить сама. Списал бы на культурные различия, но ни на англоязычных собеседованиях, ни во время исследования с Atlassian (тоже участвовал как респондент) я с таким не сталкивался.
Ещё можно принять участие, результатами обещают поделиться через пару месяцев https://medium.com/researchops-community/researching-the-repositories-get-involved-1a0f53ee2398.
____
https://t.me/uxread/131 немного про разные стили ведения интервью и probing technics
- Она в первые же минуты нашего разговора очень подробно описала весь процесс использования данных с интервью - кто будет иметь к ним доступ, как они будут расшифровываться, где будут храниться, какие задачи они хотят с помощью этого интервью решить, где и в каком виде планируют опубликовать результаты. Никогда не видел такого, очень здорово и вовлекающе.
- Сразу же при созвоне уточнила, комфортно ли мне говорить на английском, и извинилась за то, что не говорит на моём языке (это не было вызвано какими-то явными затруднениями с моей стороны - я говорю довольно свободно, но, позволило мне чувствовать себя комфортней, запинаясь).
- Чуть затянутые паузы после моих реплик. Я замолкал, после этого модератор ждала около секунды (пауза чуть длиннее естественной), и только после этого начинала говорить сама. Списал бы на культурные различия, но ни на англоязычных собеседованиях, ни во время исследования с Atlassian (тоже участвовал как респондент) я с таким не сталкивался.
Ещё можно принять участие, результатами обещают поделиться через пару месяцев https://medium.com/researchops-community/researching-the-repositories-get-involved-1a0f53ee2398.
____
https://t.me/uxread/131 немного про разные стили ведения интервью и probing technics
Medium
Researching the Repositories… Get Involved!
By Mark McElhaw, Holly Cole and Brigette Metzler
❤2
Вообще один из хороших способов прокачаться как интервьюер - участвовать в качестве респондента в исследованиях сильных модераторов. Вот тут можно добавиться в базы респондентов Atlassian, Microsoft, Salesforce, Google, Monzo и на своей шкуре почувствовать, как они проводят (если знаете, кто ещё собирает базы в открытую, напишите мне, отредактирую пост).
(Отдельное спасибо Маше за аналогичную идею с опросами, когда проходишь чужой опрос, сразу видишь нелепые ошибки, которые у себя легче пропустить)
#Recruitment
#Sessions
(Отдельное спасибо Маше за аналогичную идею с опросами, когда проходишь чужой опрос, сразу видишь нелепые ошибки, которые у себя легче пропустить)
#Recruitment
#Sessions
Исследования в LinkedIn
Супер короткий конспект о том, как устроены исследования в LinkedIn, оформленный в виде профайла одной из исследовательниц.
Это одно из самых ёмких описаний, что я встречал - всё понятно, читается за пять минут с одних заголовков. Если вам нужно за 20 минут подготовить лекцию о том, как устроены исследования в большом b2c продукте, это уже готовый конспект.
Из интересного:
• Очень чётко описана структура проекта, от kick-off, до коммуникации результато, готовая методичка
• Средний проект длится 4-6 недель, ого
• Четкое деление на foundational research, formative research и evaluative research
• Для полевых исследований есть field research kits, который включает камеру, штатив, микрофон и recording device (ноутбук?). Бестолково, но мило)
Единственное, немного пугающий язык статьи:
"Conclusion
Sunny Patel loves her job at LinkedIn, because they understand the value of user research. LinkedIn provides extensive support, necessary tools and resources to get the job done. Sunny enjoys conducting user research within LinkedIn's large ecosystem. She finds it exciting to dive deep into the world of job seekers to understand their experience. "
Чувствуете, да? Как будто Санни сейчас окажется роботом, или мы узнаем, что они клонируют респондентов, чтобы лучше контролировать случайные переменные, или ещё что-то такое странненькое, что они совершенно случайно забыли упомянуть.
Но статья, я повторюсь, норм
https://www.getcloudapp.com/blog/user-research-at-linkedin-sunny-patel
___
Как устроены исследования в других компаниях:
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, Lyft https://t.me/uxread/11 и IBM https://t.me/uxread/13 (чуть невнятно)
https://t.me/uxread/77 матрица зрелости UX исследований
#Companies
Супер короткий конспект о том, как устроены исследования в LinkedIn, оформленный в виде профайла одной из исследовательниц.
Это одно из самых ёмких описаний, что я встречал - всё понятно, читается за пять минут с одних заголовков. Если вам нужно за 20 минут подготовить лекцию о том, как устроены исследования в большом b2c продукте, это уже готовый конспект.
Из интересного:
• Очень чётко описана структура проекта, от kick-off, до коммуникации результато, готовая методичка
• Средний проект длится 4-6 недель, ого
• Четкое деление на foundational research, formative research и evaluative research
• Для полевых исследований есть field research kits, который включает камеру, штатив, микрофон и recording device (ноутбук?). Бестолково, но мило)
Единственное, немного пугающий язык статьи:
"Conclusion
Sunny Patel loves her job at LinkedIn, because they understand the value of user research. LinkedIn provides extensive support, necessary tools and resources to get the job done. Sunny enjoys conducting user research within LinkedIn's large ecosystem. She finds it exciting to dive deep into the world of job seekers to understand their experience. "
Чувствуете, да? Как будто Санни сейчас окажется роботом, или мы узнаем, что они клонируют респондентов, чтобы лучше контролировать случайные переменные, или ещё что-то такое странненькое, что они совершенно случайно забыли упомянуть.
Но статья, я повторюсь, норм
https://www.getcloudapp.com/blog/user-research-at-linkedin-sunny-patel
___
Как устроены исследования в других компаниях:
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, Lyft https://t.me/uxread/11 и IBM https://t.me/uxread/13 (чуть невнятно)
https://t.me/uxread/77 матрица зрелости UX исследований
#Companies
Zight
User Research at LinkedIn with Sunny Patel
Learn Sunny Patel's process to conduct user research at LinkedIn.
❤1
Cally.ru - русскоязычный аналог Calendly для автоназначения интервью
Сегодня расскажу про http://cally.ru
Ребята делают бесплатный (пока) и русскоязычный аналог Calendly.com и других инструментов для шедулинга встреч, можно настроить себе автоматизированный рекрут, если раньше руки не доходили и не было денег.
У всех таких инструментов общая механика - вы выбираете слоты времени, когда вам удобно провести интервью, и отправляете их другому человеку, чтобы он выбрал удобное ему и отметился там.
Из крутых отличий - в Cally в отличие от Calendly, респондент может вместо почты указать телефон, или даже ник в телеграме (если вы делаете юзабилити для дарквеба). Ну и ещё интерфейс на русском.
Если вы про Calendly (или Сally) не знаете, то это один из самых полезных инструментов для исследователя, если вы рекрутите сами. Процесс хорошо описан у wework в той же статье про базы инсайтов и continuous research http://tinyurl.com/y6g5k65n.
Они захотели тратить меньше времени на рекрут и автоматизировать его. Что сделали:
1) Запихнули на сайт, в рассылку, опросники саппорта и другие точки контакта призыв "хотите пройти исследование" со ссылкой на опрос?
2) Опрос сегментировал клентов.
3) Нужному сегменту рассылались приглашалки на исследование, в приглашалке была ссылка на Сalendly. Клиент переходил, выбирал нужный слот, записывался, встреча автоматом проставлялась в календарь и респонденту, и исследователю. Никаких согласований в почте, никаких рекрутеров, каждый четверг забит автоматически запланированными интервью, магия.
Cally в бете, только развиваются, и поэтому бесплатный. Вот тут можно заказать демку:
http://cally.ru/p/stimesdesign/speak, эта же страница хорошо иллюстрирует, как работает сервис.
___
Ещё про инструменты и автоматизацию процессов в исследованиях
https://t.me/uxread/46 Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, sheduling встреч, составление отчётов)
https://t.me/uxread/8 Как mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/148 zoom+otter для автотранскрипта интервью.
#ResarchNocode
#Operations
Сегодня расскажу про http://cally.ru
Ребята делают бесплатный (пока) и русскоязычный аналог Calendly.com и других инструментов для шедулинга встреч, можно настроить себе автоматизированный рекрут, если раньше руки не доходили и не было денег.
У всех таких инструментов общая механика - вы выбираете слоты времени, когда вам удобно провести интервью, и отправляете их другому человеку, чтобы он выбрал удобное ему и отметился там.
Из крутых отличий - в Cally в отличие от Calendly, респондент может вместо почты указать телефон, или даже ник в телеграме (если вы делаете юзабилити для дарквеба). Ну и ещё интерфейс на русском.
Если вы про Calendly (или Сally) не знаете, то это один из самых полезных инструментов для исследователя, если вы рекрутите сами. Процесс хорошо описан у wework в той же статье про базы инсайтов и continuous research http://tinyurl.com/y6g5k65n.
Они захотели тратить меньше времени на рекрут и автоматизировать его. Что сделали:
1) Запихнули на сайт, в рассылку, опросники саппорта и другие точки контакта призыв "хотите пройти исследование" со ссылкой на опрос?
2) Опрос сегментировал клентов.
3) Нужному сегменту рассылались приглашалки на исследование, в приглашалке была ссылка на Сalendly. Клиент переходил, выбирал нужный слот, записывался, встреча автоматом проставлялась в календарь и респонденту, и исследователю. Никаких согласований в почте, никаких рекрутеров, каждый четверг забит автоматически запланированными интервью, магия.
Cally в бете, только развиваются, и поэтому бесплатный. Вот тут можно заказать демку:
http://cally.ru/p/stimesdesign/speak, эта же страница хорошо иллюстрирует, как работает сервис.
___
Ещё про инструменты и автоматизацию процессов в исследованиях
https://t.me/uxread/46 Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, sheduling встреч, составление отчётов)
https://t.me/uxread/8 Как mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/148 zoom+otter для автотранскрипта интервью.
#ResarchNocode
#Operations
For The Record
How to build a UX research system that runs on autopilot
Develop faster user insights by automating your research.
Пользуясь случаем и каналом почти на 600 человек скажу, что группа Хадн дадн очень смешная)
Теперь, когда нас уже значительно меньше 600, вернёмся к исследованиям.
Ableton - софт для написания музыки, такой "скетч" для музыкантов, в котором можно собирать треки.
Им уже лет 20, это одна из самых популярных программ такого рода в мире, там куча сценариев, модулей и режимов. Короче он довольно навороченный, но при этом неожиданно удобный.
Почитал, что у них с юзер ресёрч:
https://medium.theuxblog.com/a-glimpse-into-user-research-at-ableton-7a9d9fee3dc2 статья от 16-года, новее пока не видел
https://speakerdeck.com/topotropic/dont-do-it-alone-user-research-at-ableton?slide=12 - того же времени преза, короткая, но очаровательная
Что круто:
1. Очень плотная работа с пользователями, понятно. Во-первых, половина команды - сами музыканты, во-вторых, есть своя панель респов на 15000 человек (!), в-третьих есть пул супер лояльных клиентов, которых они подключают на всех этапах создания фичи для collaborative design сессий и более неформальной обратной связи (похоже на вариацию на тему IBM trusted users).
2. Насчёт панели на 15 тысяч - тут все просто, они не прячут эту возможность на страничку на окраинах, как обычно, а открыто выносят в личный кабинет. В настройках профиля, там же, где вы меняете пароль и опции подписки, можно указать, хотите ли вы участвовать в исследованиях.
3. Последние годы стараются добавить больше diversity в исследования, и проводить интервью не только со средним пользователем - белым male продюссером (ребята из Берлина), но и с другими людьми (тут не знаю, diversity - хорошо, но пол или раса для выделения отдельной группы пользователей для тестирования похоже на откат к соцдем критериями сегментации, не понимаю, как это влияет на сценарии. Мб не так понял).
4. Ещё нетипично - отдают сырые версии и прототипы trusted пользователям поиграть домой, т.к. считают, что контекст и настроение для создания музыки очень важны, и в лаборатории некоторые инсайты (и нужный вайб) просто не поймать. Пользователи играются дома и потом делятся, как им. Про contextual inquiry или хотя бы просто полевые исследования не пишут почему-то, хотя напрашивается.
5. Исследователи распределены по продуктовым командам. Чтобы сохранить исследовательскую культуру и не закиснуть есть research guild в виде общего чатика в Слаке и посиделок раз в месяц с обсуждением кейсов, плюс иногда исследователи тестируют в парах, чтобы думать друг об друга.
6. Маленькая и практичная деталь - в календаре после каждого интервью забронировано время под короткое резюме и анализ сессии. Быстрое резюме после интервью делают все (очень экономит время на отчёт), но почему-то не видел раньше, чтобы это было формализовано в виде отдельной встречи, милота.
7. Ещё пишут про демократизацию исследований (это 16-й год, на минуточку) - "мы воспринимаем исследователя не как отдельную позицию, а скорее как роль в проекте, которую могут выполнять разные участники". При этом есть команда профессиональных исследователей, они частично проводят сессии сами, а частично участвуют в роли менторов, и помогают остальным участникам команды. "Исследователь как роль, а не выделенная позиция" звучит слишком радикально даже для меня, но у них, кажется, работает, может быть за счёт сильного менторства.
Про что они не написали, так это про железо - у них есть свой midi-контроллер, идеально интегрированный с софтом. Про его тестирование в статье нет ни слова :(
Найду - напишу тут.
___
А как у других?
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна
Процессы исследований в Mesosphere https://t.me/uxread/8, Atlassian https://t.me/uxread/39, LinkedIn https://t.me/uxread/121, Spotify https://t.me/uxread/104, Facebook https://t.me/uxread/71, Lyft https://t.me/uxread/11,
https://t.me/uxread/77 матрица зрелости UX исследований
#Companies
#Recruitment
#b2bResearch
Теперь, когда нас уже значительно меньше 600, вернёмся к исследованиям.
Ableton - софт для написания музыки, такой "скетч" для музыкантов, в котором можно собирать треки.
Им уже лет 20, это одна из самых популярных программ такого рода в мире, там куча сценариев, модулей и режимов. Короче он довольно навороченный, но при этом неожиданно удобный.
Почитал, что у них с юзер ресёрч:
https://medium.theuxblog.com/a-glimpse-into-user-research-at-ableton-7a9d9fee3dc2 статья от 16-года, новее пока не видел
https://speakerdeck.com/topotropic/dont-do-it-alone-user-research-at-ableton?slide=12 - того же времени преза, короткая, но очаровательная
Что круто:
1. Очень плотная работа с пользователями, понятно. Во-первых, половина команды - сами музыканты, во-вторых, есть своя панель респов на 15000 человек (!), в-третьих есть пул супер лояльных клиентов, которых они подключают на всех этапах создания фичи для collaborative design сессий и более неформальной обратной связи (похоже на вариацию на тему IBM trusted users).
2. Насчёт панели на 15 тысяч - тут все просто, они не прячут эту возможность на страничку на окраинах, как обычно, а открыто выносят в личный кабинет. В настройках профиля, там же, где вы меняете пароль и опции подписки, можно указать, хотите ли вы участвовать в исследованиях.
3. Последние годы стараются добавить больше diversity в исследования, и проводить интервью не только со средним пользователем - белым male продюссером (ребята из Берлина), но и с другими людьми (тут не знаю, diversity - хорошо, но пол или раса для выделения отдельной группы пользователей для тестирования похоже на откат к соцдем критериями сегментации, не понимаю, как это влияет на сценарии. Мб не так понял).
4. Ещё нетипично - отдают сырые версии и прототипы trusted пользователям поиграть домой, т.к. считают, что контекст и настроение для создания музыки очень важны, и в лаборатории некоторые инсайты (и нужный вайб) просто не поймать. Пользователи играются дома и потом делятся, как им. Про contextual inquiry или хотя бы просто полевые исследования не пишут почему-то, хотя напрашивается.
5. Исследователи распределены по продуктовым командам. Чтобы сохранить исследовательскую культуру и не закиснуть есть research guild в виде общего чатика в Слаке и посиделок раз в месяц с обсуждением кейсов, плюс иногда исследователи тестируют в парах, чтобы думать друг об друга.
6. Маленькая и практичная деталь - в календаре после каждого интервью забронировано время под короткое резюме и анализ сессии. Быстрое резюме после интервью делают все (очень экономит время на отчёт), но почему-то не видел раньше, чтобы это было формализовано в виде отдельной встречи, милота.
7. Ещё пишут про демократизацию исследований (это 16-й год, на минуточку) - "мы воспринимаем исследователя не как отдельную позицию, а скорее как роль в проекте, которую могут выполнять разные участники". При этом есть команда профессиональных исследователей, они частично проводят сессии сами, а частично участвуют в роли менторов, и помогают остальным участникам команды. "Исследователь как роль, а не выделенная позиция" звучит слишком радикально даже для меня, но у них, кажется, работает, может быть за счёт сильного менторства.
Про что они не написали, так это про железо - у них есть свой midi-контроллер, идеально интегрированный с софтом. Про его тестирование в статье нет ни слова :(
Найду - напишу тут.
___
А как у других?
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна
Процессы исследований в Mesosphere https://t.me/uxread/8, Atlassian https://t.me/uxread/39, LinkedIn https://t.me/uxread/121, Spotify https://t.me/uxread/104, Facebook https://t.me/uxread/71, Lyft https://t.me/uxread/11,
https://t.me/uxread/77 матрица зрелости UX исследований
#Companies
#Recruitment
#b2bResearch
Как мы в Acronis вели базу 2 года, и почему разочаровались
Года полтора назад и ещё десять раз потом я ссылался на статьи Tomer Sharon про базу инсайтов, примерно тогда же мы сделали свою в Airtable, потом забили, потом начали опять, и сейчас, наконец, она начинает приносить пользу. Расскажу, как работает, и почему теперь я сомневаюсь в том, что она нужна).
Работает просто (если чётко понимаете, как у Шерона, можно скипать) - у нас есть таблица с кучей атомарных (понятных и ценных вне контекста) инсайтов, размеченных тегами. Когда кто-то хочет понять, как работает онбординг, как устроена обычная сессия работы с продуктом, или какие проблемы есть у раздела настроек, я могу по тегам найти нужные инсайты и сделать отчёт прямо в Airtable - он позволяет создавать и шарить кастомные view с преднастроенными фильтрами и отображением, более наглядные для широкой публики, чем стандартная таблица.
Можно сделать отдельные view для каждой продуктовой команды, а ещё отдельный для маркетинга, с упором на purchase motivation инсайты. Они будут играть роль дашбордов для качественных данных (view динамически обновляются, если вы добавляете в базу новые данные, которые попадают под фильтры). Это всё работает и действительно помогает быстрее отвечать на некоторые вопросы о пользователях.
Что ещё круто:
- Кроме скорости база даёт необычные ракурсы - можно увидеть, какие проблемы возникают, например, именно у профессиональных пользователей, или именно в маленьких компаниях, сделав общий срез для нескольких исследований.
- Теперь понятно, куда девать все нецелевые проблемы, которые вы получили "между делом", и которые не хочется терять, но прямо сейчас не к месту.
- База держится на идее атомарных инсайтов, которые должны хорошо восприниматься вне контекста отчёта, в том числе человеком, который про изначальное исследование вообще не знает. Это учит описывать проблемы более чётко.
Теперь минусы:
- Базу тегов для поиска довольно утомительно поддерживать. Пока наше решение - избыточность. Если пишу про проблемы алёртов, то ставлю теги "alerts", "troubleshooting" и ещё парочку, в зависимости от контекста, чтобы нужное точно нашлось. Из-за этого во view может попасть много нерелевантных инсайтов по теме, но они легко отсекаются сужением фильтров.
- Чтобы по тегам могли искать, нужно, чтобы у команды был общий язык для элементов интерфейса и сценариев. Формального процесса для создания общего языка нет, пока работает само. Новичкам может быть сложно, потому что они общепринятых терминов ещё не усвоили.
- На базу очень легко забить, особенно пока данных для нормальных срезов недостаточно и работать "по запросу" она не может. Чтобы этого не случилось, мы постарались использовать её для создания отчётов, которые не требуют красивой презентации, так мотивации заполнять больше.
- Не развалится ли это всё при масштабировании, когда людей, команд и инсайтов будет больше? Не знаю:)
Несмотря на плюсы, я теперь сомневаюсь, что базу стоит вести регулярно, поделюсь сочинениями чуть позже.
#Process #Processing #Research_repo
Года полтора назад и ещё десять раз потом я ссылался на статьи Tomer Sharon про базу инсайтов, примерно тогда же мы сделали свою в Airtable, потом забили, потом начали опять, и сейчас, наконец, она начинает приносить пользу. Расскажу, как работает, и почему теперь я сомневаюсь в том, что она нужна).
Работает просто (если чётко понимаете, как у Шерона, можно скипать) - у нас есть таблица с кучей атомарных (понятных и ценных вне контекста) инсайтов, размеченных тегами. Когда кто-то хочет понять, как работает онбординг, как устроена обычная сессия работы с продуктом, или какие проблемы есть у раздела настроек, я могу по тегам найти нужные инсайты и сделать отчёт прямо в Airtable - он позволяет создавать и шарить кастомные view с преднастроенными фильтрами и отображением, более наглядные для широкой публики, чем стандартная таблица.
Можно сделать отдельные view для каждой продуктовой команды, а ещё отдельный для маркетинга, с упором на purchase motivation инсайты. Они будут играть роль дашбордов для качественных данных (view динамически обновляются, если вы добавляете в базу новые данные, которые попадают под фильтры). Это всё работает и действительно помогает быстрее отвечать на некоторые вопросы о пользователях.
Что ещё круто:
- Кроме скорости база даёт необычные ракурсы - можно увидеть, какие проблемы возникают, например, именно у профессиональных пользователей, или именно в маленьких компаниях, сделав общий срез для нескольких исследований.
- Теперь понятно, куда девать все нецелевые проблемы, которые вы получили "между делом", и которые не хочется терять, но прямо сейчас не к месту.
- База держится на идее атомарных инсайтов, которые должны хорошо восприниматься вне контекста отчёта, в том числе человеком, который про изначальное исследование вообще не знает. Это учит описывать проблемы более чётко.
Теперь минусы:
- Базу тегов для поиска довольно утомительно поддерживать. Пока наше решение - избыточность. Если пишу про проблемы алёртов, то ставлю теги "alerts", "troubleshooting" и ещё парочку, в зависимости от контекста, чтобы нужное точно нашлось. Из-за этого во view может попасть много нерелевантных инсайтов по теме, но они легко отсекаются сужением фильтров.
- Чтобы по тегам могли искать, нужно, чтобы у команды был общий язык для элементов интерфейса и сценариев. Формального процесса для создания общего языка нет, пока работает само. Новичкам может быть сложно, потому что они общепринятых терминов ещё не усвоили.
- На базу очень легко забить, особенно пока данных для нормальных срезов недостаточно и работать "по запросу" она не может. Чтобы этого не случилось, мы постарались использовать её для создания отчётов, которые не требуют красивой презентации, так мотивации заполнять больше.
- Не развалится ли это всё при масштабировании, когда людей, команд и инсайтов будет больше? Не знаю:)
Несмотря на плюсы, я теперь сомневаюсь, что базу стоит вести регулярно, поделюсь сочинениями чуть позже.
#Process #Processing #Research_repo
Почему теперь я не уверен, что база инсайтов нужна:
1) Хранилище знаний не так важно, как налаженный процесс создания. Интуитивно кажется, что запас чего угодно (в том числе знаний) - это хорошо.
На самом деле - нет, потому что запасы впрок - это вложенные ресурсы, которые пока не приносят вам прибыли. Вы уже потратили время на исследование, но пока инсайт лежит в базе неприменённый, пользу он ещё не принёс. Чем больше таких неиспользованных знаний, тем больше времени вы пока потратили, не принеся ценности. Со временем инсайты "протухают" и становятся менее ценными.
(я понимаю, что Голдраттовскую метафору стоит использовать ограниченно, потому что знания можно переиспользовать, а детали - нет, но пока вроде нормально, да?)
Это приводит нас к идее, что до создании хранилища знаний стоит наладить хорошую логистику их получения - быстрые исследования, continuous research и регулярный доступ к респондентам, много исследовать "впрок" не стоит, и знания стоит применять поскорее.
Это не касается результатов foundational research, которые устаревают медленней, и которые мы можем переиспользовать много раз, но доля таких исследований мала.
Про быстрые исследования и хороший доступ респондентам много пишет Контур (между делом скажу, что в Контуре работают просто бешеные ребята и девушки, их гайды всегда полны здравомыслия, отвешиваю реверанс).
2) Хранилище знаний не так важно, как налаженный процесс его доставки до команды. Одна из задач исследований - создавать user centered культуру и более сильное "чувство пользователя". Само наличие базы знаний эту культуру не улучшает, также как библиотеки сами по себе не повышают грамотность. Для этого нужно то, что Трэвис называет information radiators - постеры, встречи, дайджесты, т.е. способы не просто хранить знание, а доставлять его. Вы будете сильнее влиять на команду, если научитесь быстренько отгружать порции инсайтов и доносить их в понятной форме, чем если потратите время на огромный склад с системой хранения.
Тут ещё хочется сказать про то, что обтёсывая наблюдения в atomic insights мы отбрасываем часть информации. Поэтому чувство пользователя лучше всего нарабатывается непосредственным наблюдением, и гораздо хуже - списками инсайтов по теме (очень хочется вставить метафору, что база знаний помогает лучше принимать решения канемановской системе 2, а непосредственное участие в исследованиях повышает фоновое качество решений системы 1, но это уже явный перебор)
3) Почти ничего не важно. Третья причина (👨🦰🎶 🎹) в том, что мой внутренний фокус сместился от "как построить конвейер исследований, проверить каждую кнопочку, залезть пользователю в душу и ничего не упустить" ближе к "как понять, где важнее всего повысить качество решений, сфокусироваться на этом, и забить на остальное". Теперь не так хочется покрыть все продуктовые решения обратной связью, и большая всеохватывающая база знаний кажется не настолько важной.
Вести мы её всё равно продолжим) Посмотрим, как пойдёт.
___
Ещё про базы инсайтов
https://t.me/uxread/44 Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/38 Мейлчимп сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#bases
1) Хранилище знаний не так важно, как налаженный процесс создания. Интуитивно кажется, что запас чего угодно (в том числе знаний) - это хорошо.
На самом деле - нет, потому что запасы впрок - это вложенные ресурсы, которые пока не приносят вам прибыли. Вы уже потратили время на исследование, но пока инсайт лежит в базе неприменённый, пользу он ещё не принёс. Чем больше таких неиспользованных знаний, тем больше времени вы пока потратили, не принеся ценности. Со временем инсайты "протухают" и становятся менее ценными.
(я понимаю, что Голдраттовскую метафору стоит использовать ограниченно, потому что знания можно переиспользовать, а детали - нет, но пока вроде нормально, да?)
Это приводит нас к идее, что до создании хранилища знаний стоит наладить хорошую логистику их получения - быстрые исследования, continuous research и регулярный доступ к респондентам, много исследовать "впрок" не стоит, и знания стоит применять поскорее.
Это не касается результатов foundational research, которые устаревают медленней, и которые мы можем переиспользовать много раз, но доля таких исследований мала.
Про быстрые исследования и хороший доступ респондентам много пишет Контур (между делом скажу, что в Контуре работают просто бешеные ребята и девушки, их гайды всегда полны здравомыслия, отвешиваю реверанс).
2) Хранилище знаний не так важно, как налаженный процесс его доставки до команды. Одна из задач исследований - создавать user centered культуру и более сильное "чувство пользователя". Само наличие базы знаний эту культуру не улучшает, также как библиотеки сами по себе не повышают грамотность. Для этого нужно то, что Трэвис называет information radiators - постеры, встречи, дайджесты, т.е. способы не просто хранить знание, а доставлять его. Вы будете сильнее влиять на команду, если научитесь быстренько отгружать порции инсайтов и доносить их в понятной форме, чем если потратите время на огромный склад с системой хранения.
Тут ещё хочется сказать про то, что обтёсывая наблюдения в atomic insights мы отбрасываем часть информации. Поэтому чувство пользователя лучше всего нарабатывается непосредственным наблюдением, и гораздо хуже - списками инсайтов по теме (очень хочется вставить метафору, что база знаний помогает лучше принимать решения канемановской системе 2, а непосредственное участие в исследованиях повышает фоновое качество решений системы 1, но это уже явный перебор)
3) Почти ничего не важно. Третья причина (👨🦰🎶 🎹) в том, что мой внутренний фокус сместился от "как построить конвейер исследований, проверить каждую кнопочку, залезть пользователю в душу и ничего не упустить" ближе к "как понять, где важнее всего повысить качество решений, сфокусироваться на этом, и забить на остальное". Теперь не так хочется покрыть все продуктовые решения обратной связью, и большая всеохватывающая база знаний кажется не настолько важной.
Вести мы её всё равно продолжим) Посмотрим, как пойдёт.
___
Ещё про базы инсайтов
https://t.me/uxread/44 Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/38 Мейлчимп сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#bases
Telegram
UX Research
Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся (а ещё про демократизацию исследований)
WeWork рассказывают про свой подход к исследованиям Atomic Research: они отказались от отчётов по исследованиям…
WeWork рассказывают про свой подход к исследованиям Atomic Research: они отказались от отчётов по исследованиям…
👍1🔥1
Пока писал, понял, что смотрю на исследования (и пишу о них) с двух разных ракурсов, переключаясь между ними. И то же самое, кажется, делает большинство известных мне исследователей.
Первый - исследования в таком сакрально/гуманитарном ключе, как способ глубоко понять душу/разум/мотивацию пользователя с помощью, натренированной эмпатии и исследовательских практик.
Основная задача исследований - узнать что-то новое о людях. Это интересная задача сама по себе, безотносительно метрик. С этим подходом любят ассоциировать себя психологи/социологи/антропологи, и мне он интуитивно симпатичен. Но он же меня отталкивает, потому что:
- Допускает бесконечные бессмысленные споры об одних и тех же методологических вопросах по кругу
- Легко становится прибежищем для нейробулшита и научного шаманства (по логике: люди сложны->исследования сложны->нейробихевиоральный анализ в ходе когнитивного наблюдения поможет вам)
Второй - исследование как менеджмент и логистика знаний о пользователях, для повышения качества решений. Очень светский, практичный и немного огрубляющий подход, который фокусируется не на человеке, а на продуктовых задачах, и который, в идеале, оставляет меньше места для спекуляций (и реальнонаучных, и околонаучных)
Где-то между ними, вне их есть ещё "исследование как нормальная научная дисциплина", где живут благословенные HCI ребята и Сауро (этих ребят тоже скашивает в споры о методологических вопросах, но меньше), но я не там.
(Простите за размазанные формулировки, это сырые размышления, которые мне важно записать).
Первый - исследования в таком сакрально/гуманитарном ключе, как способ глубоко понять душу/разум/мотивацию пользователя с помощью, натренированной эмпатии и исследовательских практик.
Основная задача исследований - узнать что-то новое о людях. Это интересная задача сама по себе, безотносительно метрик. С этим подходом любят ассоциировать себя психологи/социологи/антропологи, и мне он интуитивно симпатичен. Но он же меня отталкивает, потому что:
- Допускает бесконечные бессмысленные споры об одних и тех же методологических вопросах по кругу
- Легко становится прибежищем для нейробулшита и научного шаманства (по логике: люди сложны->исследования сложны->нейробихевиоральный анализ в ходе когнитивного наблюдения поможет вам)
Второй - исследование как менеджмент и логистика знаний о пользователях, для повышения качества решений. Очень светский, практичный и немного огрубляющий подход, который фокусируется не на человеке, а на продуктовых задачах, и который, в идеале, оставляет меньше места для спекуляций (и реальнонаучных, и околонаучных)
Где-то между ними, вне их есть ещё "исследование как нормальная научная дисциплина", где живут благословенные HCI ребята и Сауро (этих ребят тоже скашивает в споры о методологических вопросах, но меньше), но я не там.
(Простите за размазанные формулировки, это сырые размышления, которые мне важно записать).
Написал про UX Curve (способ для исследования опыта в динамике, дешёвая замена дневников).
Писал о нём тут выше, но в этот раз разобрался поглубже. Из интересного - он, оказывается, работает в несколько раз лучше интервью для получения ретроспективных данных, и по качеству данных сравним с дневниками, хотя деталей даёт поменьше.
Там ещё lifetime value в заголовке - особо не ведитесь, отдельных секретов про LTV нет, это чтобы продактам чаще в выдачу попадать https://bit.ly/3eZ5y9y
____
Другие забавные исследования:
https://t.me/uxread/82 Как headspace повышали вовлечённость и улучшали онбординг в приложении по habit formation loop (по пути проведя опрос и дневники)
https://t.me/uxread/30 как Mozilla исследовали использование закладок в браузере, запрещая ими пользоваться (тоже дневники)
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Другие методы #Methods
Другие кейсы #Cases
Писал о нём тут выше, но в этот раз разобрался поглубже. Из интересного - он, оказывается, работает в несколько раз лучше интервью для получения ретроспективных данных, и по качеству данных сравним с дневниками, хотя деталей даёт поменьше.
Там ещё lifetime value в заголовке - особо не ведитесь, отдельных секретов про LTV нет, это чтобы продактам чаще в выдачу попадать https://bit.ly/3eZ5y9y
____
Другие забавные исследования:
https://t.me/uxread/82 Как headspace повышали вовлечённость и улучшали онбординг в приложении по habit formation loop (по пути проведя опрос и дневники)
https://t.me/uxread/30 как Mozilla исследовали использование закладок в браузере, запрещая ими пользоваться (тоже дневники)
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Другие методы #Methods
Другие кейсы #Cases
Medium
UX Curve для исследования опыта в динамике и работы с lifetime value
UX Сurve — исследовательский метод, который позволяет узнать, как опыт пользователя и его отношение к продукту меняется со временем.
Про разные стили ведения интервью и probing technics
У NNGroup есть несколько замечательно практичных статей про модерацию интервью.
Вот классная о том, как правильно мычать в ответ на вопросы респондента, вы её видели наверняка, а если нет - посмотрите, там прямо войсы с примерами диалогов https://www.nngroup.com/articles/talking-to-users/
Или вот ещё одна хорошая - как помалкивать, тоже с аудиопримерами https://www.nngroup.com/articles/intentional-silence-ux/
Я к чему это - недавно прошёл курсеровский курс по qualitative researсh и там есть хорошее обзорное видео по probing technics (https://www.coursera.org/learn/qualitative-methods, неделя 4, урок 3)
Probing technics (русский перевод "зондирующие техники" меня пугает, оставим англицизм), это техники ведения интервью, от хмыканья до разных типов уточняющих вопросов - все те секретные секреты модерации, которые позволяют получить от респондента более глубокие и полезные ответы.
Сам термин, судя по всему, базовый для социологов, но не встречается в контексте UX исследований.
#Methods
У NNGroup есть несколько замечательно практичных статей про модерацию интервью.
Вот классная о том, как правильно мычать в ответ на вопросы респондента, вы её видели наверняка, а если нет - посмотрите, там прямо войсы с примерами диалогов https://www.nngroup.com/articles/talking-to-users/
Или вот ещё одна хорошая - как помалкивать, тоже с аудиопримерами https://www.nngroup.com/articles/intentional-silence-ux/
Я к чему это - недавно прошёл курсеровский курс по qualitative researсh и там есть хорошее обзорное видео по probing technics (https://www.coursera.org/learn/qualitative-methods, неделя 4, урок 3)
Probing technics (русский перевод "зондирующие техники" меня пугает, оставим англицизм), это техники ведения интервью, от хмыканья до разных типов уточняющих вопросов - все те секретные секреты модерации, которые позволяют получить от респондента более глубокие и полезные ответы.
Сам термин, судя по всему, базовый для социологов, но не встречается в контексте UX исследований.
#Methods
Nielsen Norman Group
Talking with Users in a Usability Test
Three sound and practical usability test facilitation techniques for interrupting or answering users during a behavioral research study. Talk less, learn more.